Summary:
1. skip zero count
2. no need to check last binding count on the restore path
3. flatten the helper to avoid a 2nd pass in free_descriptors
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28563>
This is to balance with other checks against it, and meanwhile making it
explicit that real descriptor free shouldn't call the free helper.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28563>
The ring cs shmem cache is already there. The external fence/sempahore
support will be eventually via adopting mesa common drm syncobj support.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28532>
The two extensions are implemented natively but allow to leak structs to
renderer side to avoid deep copying huge driver side pNext chain. It
doesn't make things more robust if we hide the two behind core 1.3 and
drop the two from the protocol so that venus-protocol filters out the
leaked structs. e.g. we'd still have to flip some bits in the core
feature structs.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28532>
The default vn_relax is mainly targeting Vulkan commands expecting a
rely like object creation and property queries. The defined relax reason
here is VN_RELAX_REASON_RING_SPACE. The polling strategy involves more
busy waits to overcome sleep penalty affecting cpu utilization, as well
as an edge case for Android system server which forces to sleep longer
even with trivial hrtimer interval.
However, for the below relax reasons:
- VN_RELAX_REASON_RING_SPACE
- VN_RELAX_REASON_FENCE
- VN_RELAX_REASON_SEMAPHORE
- VN_RELAX_REASON_QUERY
It's a waste of cpu cycles if we do more busy waits if the initial
polled signals are not "ready". Having less busy waits there allows to
jump to higher order of sleeps sooner to disturb the scheduler less
until signaled.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28287>
Up to this commit in this MR, the gfxbench manhattan scores have been
improved by 10~15% with ANGLE-on-Venus on some AMD platforms.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28287>
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>
Similar to the rationale for the 50ms -> 5ms adjustment before. When
there's enough cpu cycles, doing so would only help reduce cpu
utilization. When cpu is mostly drained, less host side unnecessary
polling is favored by the scheduler. Also in the latter case, it'd be
the non-primary ring, so it doesn't hurt to idle out faster.
Besides the theory, there's no regression in popular benchmarks, but
only power wins. Making the idle timeout too small will lead to overhead
built up. e.g. From the initial notify to ring being waken up, it's
about 200us. The notify op is more expensive than ring thread doing a
few more polls. However, we normally would save many more polls by idle
out earlier. From my local testing, reducing down to 500us won't incur
and real perf regressions either.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28287>
The ring notification can be blocked on renderer main thread if a vq cmd
is waiting for a ring cmd (via a different non-idle ring). This change
optimizes to only try waking up the ring on the idle timeout period.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28287>
Extend the vkGetPhysicalDeviceFormatProperties2 cache to include
VkFormatProperties3 from the pNext chain. VkFormatProperties3 was
observed being always attached for DXVK and thus skipping the cache
if not handled.
Signed-off-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28194>
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>
A roundtrip is to ensure a cmd via virtqueue happens on the renderer
side before a ring relies on it. Since venus is now with multi-ring, the
roundtrip submit and wait should belong to ring instead of instance, and
each ring owns its own roundtrip seqno to synchronize with virtqueue.
No behavior change.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28147>
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>
Drop vn_combine_query_records_and_record_feedback to save the lines of
codes for args preparing. Also refactor to avoid the cmd stride trick,
but use indexing.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28112>
1. move record into alloc to simplify caller handling, which aligns
with ffb and sfb as well
2. simplify locking to reduce lock overhead
3. remove unbalanced free from record helper
4. move reset to alloc
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>
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>
The prior refactor has missed a case that timeline sempahore can be
ping-pong'ed between device signal and host wait.
Fixes: d63432012d ("venus: refactor semaphore feedback")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reported-by: Juston Li <justonli@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27807>
