The check won't reduce much of the overhead but also adds more when
something is to be fixed (mostly the case for push descriptor).
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28563>
For guest vram, there's already roundtrip to protect device memory alloc
ordering. This change adds the same protection for shmem used in below
scenarios and optimize to wait for new shmem only.
- reply shmem
- indirect upload shmem
- cmd stream shmem
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28147>
Add a new free helper while renaming the alloc one as well. During query
record resolving, use a dropped list to store those records being reset.
This is to prepare for later further query record resolving.
This change also simplifies a query pool compare.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28112>
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>
Instead of just recyling 1 linked query feedback cmd for use and
defering the actualy recycle, recycle all linked cmds found when
setting up submission immediately.
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27163>
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>
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>
This is to prepare for a new multi-ring design. A preview is as below:
- primary ring will migrate to be asynchronous only
- synchronous commands will be via thread local rings
- pipeline creations will be synchronous and dispatched to thread local
rings unless being forced to be async on primary ring
- perf option no_multi_ring is made generic to force a single ring
Pipeline cache retrieval is temporarily moved back to primary ring, but
will be moved to thread local later since it's a synchronous command.
The dependency resolving will follow the same with pipeline create with
detailed rationale later.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26838>
Summary:
- Add a perf option to force primary ring submission
- Let device own secondary ring(s) for ad-hoc spawn
- For threads where swapchain and command pool are created, track with
TLS to instruct ring dispatch.
- If the pipeline creation or cache retrieval happens on the background
threads not on the hot paths, force synchronous and dispatch to the
secondary ring after waiting for primary ring becoming current.
- If the pipeline creation or cache retrieval happens on the hot paths
threads, dispatch to the primary ring to avoid being blocked by those
tasks on the secondary ring.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26179>
Sync protocol and fix all the interfaces, otherwise we have to generate
two sets of headers with both interfaces to separate protocol sync and
the driver side adaptation.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26179>
All commands that make queries available have feedback cmds batched
and stored during recording. At submission time, for each batch
(SubmitInfo) these feedback cmds are recorded in a cmd buffer that is
appended after the last original cmd buffer (but before
semaphore/fence feedback).
Query reset cmds are deferred as well and also remove any prior feedback
cmds for queries its resetting within the batch.
Cc: 23.3 <mesa-stable>
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25413>
Link the query feedback cmd lifecycle to a cmd in the batch so that when
that last cmd gets reset/freed, we assert its safe to reset the query
feedback cmd. The cmd is then placed on the free list for reuse.
Some edge cases if the the last cmd is simultaneous or gets resubmitted.
Cc: 23.3 <mesa-stable>
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25413>
Add function to alloc a cmd buffer and record all the deferred query
feedback cmds into it at submission time.
Cc: 23.3 <mesa-stable>
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25413>
Should only log when there's batched query feedbacks in the suspended
render pass instance. Additionally gate behind debug option.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24379>
For secondary command buffers, vn_cmd_begin_render_pass was only used to
track inherited render pass previously. So we clean it up.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24103>
Reset cmd states during vkBeginCommandBuffer regardless of the
VK_COMMAND_POOL_CREATE_RESET_COMMAND_BUFFER_BIT for simplicity.
Cc: mesa-stable
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24103>
There's no functional changes:
1. remove unused function arg and use snake case
2. do early return for direct recording (avoid dup feedback checks)
3. use vk_alloc instead of vk_zalloc if applicable
4. move local struct closer to usage, and use assignment
5. convert secondary cmd in_render_pass condition check to assert
6. avoid redundant list_del upon freeing up
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24009>
Create a feedback buffer for each query pool and retrieve the query
results from the buffer instead of a roundtrip call in
vkGetQueryPoolResults.
VK_QUERY_RESULT_WAIT_BIT queries will poll until the queries are
available in the feedback buffer.
Query results in the feedback buffer are always VK_QUERY_RESULT_64_BIT
and if needed converted to what the app requests at
vkGetQueryPoolResults time.
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23348>
vkCmdCopyQueryPoolResults cannot be called within a render pass so batch
and defer the query feedback copies until after the render pass.
Secondary command buffers inside render passes also have their query
feedback copies batched when recorded. When the secondary command buffer
is recorded via vkCmdExecuteCommands, it's batch is merged into the
primary command buffer's batch and is defered until the render pass ends.
If multiview is enabled, vkCmdCopyQueryPoolResults needs to copy
additional queries matching the number of bits set in viewMask.
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23348>
vkCmdCopyQueryPoolResults cannot be called within a render pass/or
while the render pass is suspended so track when commands are inside
a render pass. Also track whether a secondary command buffer is
considered to be entirely inside a render pass.
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23348>
Per spec 1.3.255: "If queries are used while executing a render pass
instance that has multiview enabled, the query uses N consecutive query
indices in the query pool (starting at query) where N is the number of
bits set in the view mask in the subpass the query is used in."
track viewMask so query feedback can copy the correct amount of queries
when multiview is enabled.
viewMask is passed in for vkCmdBeginRendering but for legacy
vkCmdBeginRenderPass/2 they are set by vkCreateRenderPass for each
subpass.
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23348>
