vk_common_QueueWaitIdle() creates a syncobj, does a submit with no
batch buffers what translates to execute trivial_batch_bo and then
waits for syncobj to be signaled when trivial_batch_bo finishes.
On Xe KMD on other hand we can avoid the trivial_batch_bo submission
and instead use the special DRM_IOCTL_XE_EXEC with num_batch_buffer == 0
to get a syncobj to be signaled when the last exec finish execution.
This should free a bit GPU to execute more important workloads.
This will also optimize vkDeviceWaitIdle() that calls QueueWaitIdle().
It have to fallback to vk_common_QueueWaitIdle() when queue is in
VK_QUEUE_SUBMIT_MODE_THREADED mode because vkQueueWaitIdle()
could return but there still stuff in VK/CPU submission queue.
Also it could cause use after free when resources attached to
submission are freed before it is processed, example:
vkCreateFence() or vkCreateSemaphore()
vkQueueSubmit() // with Fence or Semaphore created above
vkQueueWaitIdle() // with the race it returns
vkDestroyFence() or vkDestroySemaphore()
// vk_queue_submit_thread_func() start to process submission above...
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30958>
Split anv_xe_wait_exec_queue_idle() into 2 functions, the first
function creates the syncobj and prepares it to be signaled when the
last workload in queue is completed.
And the second one that calls the first function, then waits for the
syncobj to be signaled and destroy the syncobj.
The main reason for that is that the first function can be reused in
Iris and a future patch will add another user, so lets share it.
No changes in behavior are expected here.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30958>
We currently disable CCS if a 3D Ys/Yf surface uses miptails. However,
ISL generally configures surfaces to be compatible with compression. For
consistency, disable miptails on 3D Ys/Yf surfaces in order to allow
compression.
If drivers prefer to have a more compact layout, they can pass the
ISL_SURF_USAGE_DISABLE_AUX_BIT flag at surface creation time.
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30081>
We currently disable CCS if a surface uses more than 11 slots in a
miptail. However, ISL generally configures surfaces to be compatible
with compression. For consistency, reduce the number of slots used in
miptails in order to allow compression.
If drivers prefer to have a more compact layout, they can pass the
ISL_SURF_USAGE_DISABLE_AUX_BIT flag at surface creation time.
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30081>
This adds gfxstream-vk as a vulkan driver to Mesa. It
will be used in the following places:
- Android Emulator
- Fuchsia Emulator
- Cloud Android
- AAOS reference hardware
- [a few other places]
meson amd64-build/ -Dvulkan-drivers="gfxstream-experimental" -Dgallium-drivers="" -Dopengl=false
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>
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>
David Rosca