We want to move more Android-related functions into common code.
Many of which require interactions with the gralloc. Therefore,
struct u_gralloc must be kept in a common code.
vk_android_get_ugralloc() must be used for gralloc API calls.
vk_android_{init|destroy}_ugralloc() must be used in Vulkan HAL
initialization code, e.g.:
- In XXXX_hal_open() to initialize the gralloc
- In XXXX_hal_close() to destroy the gralloc
We do not put gralloc initialization into the generic code because we want
it to be initialized by Zygote's Vulkan preloader, which may sometimes
preload gralloc shared libraries, thus speeding up the initialization
of user applications.
Change-Id: I2af643bd132e6cdbfed043c8c18836501764952f
Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>
Tested-by: tarsin <yuanqingxiang233@163.com>
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Reviewed-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25360>
Per section 7.7.3, the structure includes additional optional layer-specific
information, which is padded if left unset, based on the value of
max_sub_layers_minus1. The vulkan input structs have no way to specify this
per-layer information, so we just need the padding.
Reviewed-by: Hyunjun Ko <zzoon@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29001>
This mirrors RADV's pipeline behavior (which is more performant
when programs like DXVK don't use the pipeline cache functionality)
Drivers need to set the implicit cache variable to use this though
(the next patch will enable this for NVK)
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28851>
STACK_ARRAY() is used in a lot of places. When games are running we
see STACK_ARRAY() arrays being used all the time: each queue
submission uses 6, WaitSemaphores and syncobj waiting also uses them:
they're constantly present in Vulkan runtime.
There's no need for STACK_ARRAY()'s stack array to be initialized,
callers cannot not depend on it. If the number of elements is greater
than STACK_ARRAY_SIZE, then STACK_ARRAY() will just malloc() the array
and return it not initialized: anybody depending of
zero-initialization is going to break when the array is big.
The reason why we're zero-intializing STACK_ARRAY()'s stack array is
to silence -Wmaybe-uninitialized warnings: see commit d7957df318
("vulkan: fix uninitialized variables"). I don't think that commit is
the ideal way to deal with the problem, so this patch proposes a
better solution.
The problem here is that zero-initializing it adds code we don't need
for every single caller. STACK_ARRAY() already has 63 callers and only
3 of them are affected by the -Wmaybe-uninitialized warining. So here
we undo what commit d7957df318 did and instead we fix the 3 cases
that actually generate the -Wmaybe-uninitialized warnings.
Gcc is only emitting those warinings because it knows that the number
of elements in the array may be zero, so the loops we have that set
elements to the array may end up do nothing, and then we pass the
array uninitialized to other functions.
For the cases related to vk_sync this is just returning VK_SUCCESS
earlier, instead of relying on the check that eventually happens at
__vk_sync_wait_many(). For the vkCmdWaitEvents() function, the Vulkan
spec says that "eventCount must be greater than 0", so the early
return doesn't hurt anybody either. In both cases we make the zero
case faster by not defining an 8-sized array, zero-initializing it,
then returning success without using it.
Reference: d7957df318 ("vulkan: fix uninitialized variables")
Acked-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28288>
This is achieved by the following steps:
#ifndef DEBUG => #if !MESA_DEBUG
defined(DEBUG) => MESA_DEBUG
#ifdef DEBUG => #if MESA_DEBUG
This is done by replace in vscode
excludes
docs,*.rs,addrlib,src/imgui,*.sh,src/intel/vulkan/grl/gpu
These are safe because those files should keep DEBUG macro is already excluded;
and not directly replace DEBUG, as we have some symbols around it.
Use debug or NDEBUG instead of DEBUG in comments when proper
This for reduce the usage of DEBUG,
so it's easier migrating to MESA_DEBUG
These are found when migrating DEBUG to MESA_DEBUG,
these are all comment update, so it's safe
Replace comment /* DEBUG */ and /* !DEBUG */ with proper /* MESA_DEBUG */ or /* !MESA_DEBUG */ manually
DEBUG || !NDEBUG -> MESA_DEBUG || !NDEBUG
!DEBUG && NDEBUG -> !(MESA_DEBUG || !NDEBUG)
Replace the DEBUG present in comment with proper new MESA_DEBUG manually
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: David Heidelberg <david.heidelberg@collabora.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28092>
Add the vk_rmv_misc_internal_description struct and list the misc_internal
member of that type in the vk_rmv_resource_create_token union, allowing
logging of different internal resources in RMV dumps.
The vk_rmv_common.h header also has the C-linkage block added in order to
enable its inclusion in C++ files.
Signed-off-by: Zan Dobersek <zdobersek@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27631>
This change adds a new generated header dep to the runtime internal
library dependencies. This ensures the headers are generated before the
below libraries are compiled:
- libvulkan_lite_runtime (already satisfied due to file sources)
- libvulkan_lite_instance
- libvulkan_runtime
- libvulkan_instance
Fixes: fe2ec50844 ("vulkan: allow building venus without libcompiler")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28062>
This is done by introduce idep_vulkan_lite_runtime, and only venus
depends on idep_vulkan_lite_runtime.
Modify the meson and source files to allow building venus without
the compiler.
See details Venus build metrics at the MR description.
gfxstream-vulkan forwards the shader to the host, and doesn't
need to convert into NIR in the guest. This results in faster
builds and less parts of Mesa to build. Also venus does the
same thing too, that's what the build is keyed on right now
as an in-tree user.
v7: By Yonggang Luo <luoyonggang@gmail.com>
Add idep_vulkan_common_entrypoints_h into vulkan_lite_runtime_deps because
vk_instance.c depends on idep_vulkan_common_entrypoints_h but vk_common_entrypoints is
not compiled in library `vulkan_lite_instance`.
Rename idep_vulkan_runtime_headers to idep_vulkan_lite_runtime_headers because
both lite/full runtime library depends on this, but lite should not depends on full
vk_meta_private.h added into vulkan_runtime_files
v6: By Yonggang Luo <luoyonggang@gmail.com>
get vulkan_lite_runtime_files and vulkan_runtime_files sorted
v5: By Yiwei Zhang <zzyiwei@chromium.org>
both vk_sampler and vk_ycbcr_conversion can stay in the lite runtime
v4: By Yonggang Luo <luoyonggang@gmail.com>
only build vk_instance.(c|h) twice for reduce compiling time
v3: By Yiwei Zhang <zzyiwei@chromium.org>
less code changes by introduce libvulkan_lite_runtime
v2: By Yonggang Luo <luoyonggang@gmail.com>
allow building Vulkan without libcompiler without compiling flags, the
venus is always built without libcompiler
v1: By Gurchetan Singh <gurchetansingh@google.com>
allow building Vulkan without libcompiler
Signed-off-by: Gurchetan Singh <gurchetansingh@google.com>
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26574>
Some people seem to have systems with more than 8 GPUs installed at
once. 256 is the maximum number of devices returned by libdrm, so using
this seems like a good choice for now.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27901>
In the fast-link case, we should just use the library shader and assume
that it's correct. We have to do this because we may not have a
precompiled shader in this case so we can't even generate the shader
hash.
In the link optimization case, we could still have a library shader
coming in from some library pipeline. That shader may happen to be
correct, in which case we can just use it and not even bother digging
around in the cache. In the more likely case, the keys won't match and
we should throw it away before we look up a different shader in the
cache and leak our reference.
Fixes: 9308e8d90d ("vulkan: Add generic graphics and compute VkPipeline implementation")
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27860>
These implementations are built on top of vk_shader. For the most part,
the driver shouldn't notice a difference between draws consuming
pipelines vs. draws consuming shaders. The only real difference is
that, when vk_driver_shader_ops::compile() is called for pipelines, a
struct vk_graphics_pipeline_state is provided. For shader objects, the
state object will be NULL indicating that all state is unknown. Besides
that, all the rest of the differences between Vulkan 1.0 pipelines,
VK_EXT_graphics_pipeline_library, and VK_EXT_shader_object are handled
by the Vulkan runtime code.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024>
This adds a new base vk_shader object along with vtables for creating,
binding, and working with shader objects.
Unlike other parts of the runtime, the new shader object code is a bit
more sanitized and opinionated than just handing you the Vulkan
entrypoints. For one thing, the create_shaders() calback takes a NIR
shader, not SPIR-V. Conversion of SPIR-V into NIR, handling of magic
meta NIR shaders, etc. is all done in common code. [De]serialization is
done via `struct blob` and the common code does a checksum of the binary
and handles rejecting invalid binaries based on shaderBinaryUUID and
shaderBinaryVersion. This should make life a bit easier for driver
authors as well as provides a bit nicer interface for building the
common pipeline implementation on top of shader objects.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27024>
Roman Stratiienko