Now sfb cmd can be VK_NULL_HANDLE on incompatible queues. Avoid passing
that to set cmd, and explicitly assert below.
Test: dEQP-VK.synchronization2.basic.timeline_semaphore.multi_queue can
properly assert on the driver side when assert is enabled.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38049>
Previously, we either have to filter out incompatible queue or disable
fence feedback. Now we track whether the queue can do feedback, and will
mark the fence feedback not pollable if the fence is submitted on an
incompatible queue.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38049>
Venus renderer side has strict entry points sanitization based on the
app requested app api version + physical device api version. So on the
driver, we should follow the same for legacy client apps.
Meanwhile, VK_PIPELINE_STAGE_NONE can't be used when we hit the sync2
emulation path, so we swap it with VK_PIPELINE_STAGE_BOTTOM_OF_PIPE_BIT
placeholder for the 2nd sync scope there.
Fixes: 07cee75c39 ("venus: layer vkQueueSubmit2 over vkQueueSubmit w/o sync2")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36830>
In the C23 standard unreachable() is now a predefined function-like
macro in <stddef.h>
See https://android.googlesource.com/platform/bionic/+/HEAD/docs/c23.md#is-now-a-predefined-function_like-macro-in
And this causes build errors when building for C23:
-----------------------------------------------------------------------
In file included from ../src/util/log.h:30,
from ../src/util/log.c:30:
../src/util/macros.h:123:9: warning: "unreachable" redefined
123 | #define unreachable(str) \
| ^~~~~~~~~~~
In file included from ../src/util/macros.h:31:
/usr/lib/gcc/x86_64-linux-gnu/14/include/stddef.h:456:9: note: this is the location of the previous definition
456 | #define unreachable() (__builtin_unreachable ())
| ^~~~~~~~~~~
-----------------------------------------------------------------------
So don't redefine it with the same name, but use the name UNREACHABLE()
to also signify it's a macro.
Using a different name also makes sense because the behavior of the
macro was extending the one of __builtin_unreachable() anyway, and it
also had a different signature, accepting one argument, compared to the
standard unreachable() with no arguments.
This change improves the chances of building mesa with the C23 standard,
which for instance is the default in recent AOSP versions.
All the instances of the macro, including the definition, were updated
with the following command line:
git grep -l '[^_]unreachable(' -- "src/**" | sort | uniq | \
while read file; \
do \
sed -e 's/\([^_]\)unreachable(/\1UNREACHABLE(/g' -i "$file"; \
done && \
sed -e 's/#undef unreachable/#undef UNREACHABLE/g' -i src/intel/isl/isl_aux_info.c
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36437>
This drops separate vn_fence_signal_wsi and vn_semaphore_signal_wsi
helpers for consistency and robustness. The behavior now aligns with the
Android WSI vkAcquireImageANDROID impl. This is to prepare for
installing an actual payload from the compositor side.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35079>
Prime blit can be used in setups like venus on lavapipe over vtest. It's
native env so Venus relies on renderer side driver to tell about the pci
info, while lavapipe doesn't implement that extension, which ends up
with mismatched gpu thus prime blit.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33956>
For most runtime usages, e.g. apitrace via zink on venus, the sfb cmds
normally don't exceed 3. So a limit of 5 cmds would be enough. This
would avoid that dEQP-VK.synchronization.basic.timeline_semaphore.chain
can easily leave 700+ free cmds in the cache.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31035>
This exists due to historical limitations which have long gone obsolete.
This persists longer due to hostorical perf issues that have recently
gone obsolete on the platforms shipping Venus. Meanwhile, clients like
skiavk and ANGLE nowadays do a better job managing suballocations. The
tiny perf win from having this giant internal pool has been beaten by
the memory waste, longer one-shot jank due to largier alloc, allocations
no need to be mapped but only because host-visible is advertised across
mem types and varies workarounds and markups needed to make alignment
work and make VVL happy. Dropping it also reduces the maintenance cost.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29362>
Pending feedback resources (cmds, buffers, slots) for timeline semaphores are
generally reclaimed for re-use during subsequent semaphore waits/queries or any
queue submission containing at least one "wait" semaphore.
They are never reclaimed in the unexpected case when all submissions only
contain "signal" timeline semaphores, which consume such resources but
are never subsequently queried or waited upon.
This strange behavior is observed in several Valve games (Portal 2,
L4D2, CS2), which all run natively on linux with their own internal
distributions of DXVK v2.0 (at time of this MR submission). A Cursory
analysis of recent DXVK history indicates that it may be gone by v2.1.
The consequence is rapid guest memory leak and host Vk resource leak,
resulting in a crash within 1-2 minutes.
Fix that leak by running the reclaimation procedure for submissions with
_any_ accompanying semaphores.
Fixes: d63432012d ("venus: refactor semaphore feedback")
Signed-off-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28915>
Better distinguish different client waiting and prepare for applying
different waiting profile for different reasons.
Default case is avoided in reason string mapping so that below can be
hit upon compilation:
- error: enumeration value ‘XXX’ not handled in switch [-Werror=switch]
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28287>
Below is the common client pattern (app, angle, zink, etc):
- a few resets for queries to be used in this batch
- optional, depending on EXT_host_query_reset
- a few queries
- incremental
- can cross query pool boundary
The HW drivers normally have faster shader path when there are too many
individual reset and copies. Without further resolving, this ends up
with linear overhead on the 2d engines. This change has largely
optimized that:
- angle: many copies => 1 copy (or 2)
- zink: many resets and copies => 1 reset and 1 copy (or 2)
and again...some more renamings around
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28112>
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>
Per v1.3.279 spec "VUID-VkDeviceGroupSubmitInfo-commandBufferCount-00083
commandBufferCount must equal VkSubmitInfo::commandBufferCount"
When adding feedback, need to check for vkDeviceGroupSubmitInfo in the
SubmitInfo pNext to update their commandBufferCount and
pCommandBufferDeviceMasks to include feedback cmds.
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28029>
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>
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>
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>
Yiwei Zhang