Batches must be ignored if batch count is zero, so all batch inspections
have to be gated behind batch count. For memcpy, it's UB if either src
or dst is NULL even when size is zero.
Side note:
- For original commit, this fixes just the memcpy UB
- For current codes, this fixes to not skip ffb batch prepare
Fixes: 493a3b5cda ("venus: refactor batch submission fixup")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28071>
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>
For submissions with an empty last batch containing no cmd buffers but
with semaphores as zink does, adding feedback to that batch would make
it no longer empty and increase submission overhead on some drivers.
Since feedback order is enforced by barriers, the feedback cmds can
instead be appended to the previous batch (if it exists) so that the
last batch remains empty.
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27830>
1. move feedback helpers into vn_feedback
2. rename related structs, helpers, etc
3. only recycle wait semaphores is enough for the submission. Later we
can further optimize to only recycle each timeline sempahore once
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27758>
No behavior change, and below is the summary:
1. simplify to drop _timeline_ from semaphore feedback naming
2. update feedback structs to use obj_handle naming
3. for vn_feedback_cmd_pool, use fb_cmd_pool variable naming
4. for vn_feedback_buffer, use fb_buf variable naming
5. for query_feedback_cmd, use qfb_cmd variable naming (already use ffb)
6. s/submit_batches2/submit2_batches/
7. s/cmd_buffer_count/cmd_count/
8. use total_cmd_size instead of cmd_buffer_size if applicable
9. update vn_queue_submission's feedback_cmd_count to cmd_count
10. update setup time local feedback_cmd_count to extra_cmd_count
11. update feedback_event_cmd to event_feedback_cmd
12. other trivial renames
Most semaphore and query feedback cmd renamings are deferred to later
commits.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27758>
Previously we always put fence feedback cmd in a new batch appended,
which ends up with a separate execbuf for most drivers. This change
updates to avoid that separate eb except for empty submission with just
a feedback fence.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27649>
Cache for vkGetPhysicalDeviceImageFormatProperties2 as it is observed
to be called repeatedly with zink/proton layers.
Cache design is the same as the image requirements cache, generating
a hash key from pImageFormatInfo and storing pImageFormatProperties
into a hash table.
There are a couple differences though:
- VkResult gets cached when the query returns NOT_SUPPORTED.
- Unlike pMemoryRequirements that returns VkMemoryRequirements2 and
possibly VkMemoryDedicatedRequirements, VkImageFormatProperties2
has various pNext chains that can be optionally passed in. Hash
the existence of these pNext so that they are considered different
queries and the underlying pNext struct can be optionally cached.
The alternative would be to modify the query to always chain these
pNext so all of them would be cached, but it is unlikely for queries
to only differ in pNext chains.
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27401>
This works around some Unity engine behaivor with ANGLE-on-Venus, when
cmd pools are created on main thread once while the render thread only
does descriptor pool creation for set allocations during recording time.
This change also explicitly forces async pipeline create for threads
creating the device instead of implicitly via feedback cmd pool create.
This ensures intended behavior when feedback is disabled.
Fixes: d17ddcc847 ("venus: dispatch background shader tasks to secondary ring")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27347>
The list free_query_feedback_cmds for recycling query feedback cmds was
only used in vn_command_pool when it was a vn_feedback_cmd_pool.
For clarity, refactor and store this list in vn_feedback_cmd_pool
instead and introduce a new struct vn_query_feedback_cmd that references
the feedback cmd and the feedback cmd pool for tracking.
Refactor out the allocation portion of query feedback cmds into its own
function for allocating the new vn_query_feedback_cmd struct.
Fixes: 5b24ab91e4 ("venus: switch to unconditionally deferred query feedback")
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27163>
This fixes VUID-vkCmdDraw-None-08600 violation when running gpl cts:
dEQP-VK...graphics_library.misc.bind_null_descriptor_set.*, where the
final pipeline layout is falsely dropped, leading to incompatible with
the pipeline layout of the bound descriptor set.
Fixes: a65ac274ac ("venus: Do pipeline fixes for VK_EXT_graphics_pipeline_library")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27054>
The render pass (legacy or dynamic) can be ignored only in a pipeline
library with just Vertex Input State. For other cases, even when raster
has been discarded, it is still needed at the api level to avoid
violating a bunch of VUs which validate against attachments. The legacy
pass byitself is also necessary to tell whether it's legacy or dynamic.
So venus implemented at the VK api level should not drop render pass in
those cases.
The layout to be ref'ed is the one to be used, so we don't care about
those being ignored, which has already been removed in the pipeline info
fix.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27054>
Currently driver side heap alloc obj ptr is used as object id, which is
used on the renderer side for actual vk obj mapping. However, this adds
an implicit dependency between any driver obj destroy/free and new obj
create/allocate because the heap obj freed up can be immediately
reallocated out.
With venus moving to multi-ring, the ordering between asynchronous obj
destroy/free and new obj create/allocate has to be guaranteed via driver
side non-primary ring submission always waiting for primary ring idle.
This can defeat the purpose of multi-ring in certain scenarios. So this
change adds a way to assign unique id to object.
Even before multi-ring, the unique object id can make device and queue
object alloc/free more robust without hidden ordering requirements. This
also fixes some oom cts which can intentionally fail the submission of
an object destroy (renderer side obj is still present) while the driver
side freed object ptr being reused for another object creating, causing
object id reuse at renderer side object table.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27083>
ring_seqno_valid indicates a successful ring cmd submission, and can be
used to avoid invalid reply decoding due to failed submit alloc.
Otherwise, the garbled VkResult will mislead into initialization failure
instead of oom.
Below cts failure is fixed:
dEQP-VK.api.device_init.create_instance_device_intentional_alloc_fail.basic
Fixes: ec131c6e55 ("venus: use instance allocator for ring allocs")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27026>
Yiwei Zhang