We don't actually use any of the new features, but that's okay, it's
still valid DXIL at the higher shader models.
Reviewed-by: Giancarlo Devich <gdevich@microsoft.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18022>
Set cmd->trace_renderpass_end after tu6_emit_tile_store in case of gmem.
To be able to do that, we push the update of cmd->trace_renderpass_end
down into tu_cmd_render_tiles/tu_cmd_render_sysmem.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18238>
When the renderer supports sync_fd import for the binary semaphore,
venus can import the special signaled payload to the semaphore instead
of scrubing it. This avoids the bugs w.r.t timeline semaphore and device
group submission in the legacy scrub path.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17975>
Instead of waiting for signal before importing, we are able to retain
the imported sync file and handle the fence related commands on the
driver side.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17975>
Simplify Android wsi to only use performant path if fixed sync_fd fence
support is enabled. This removes hacky codes and allows us to deprecate
a special ring wait code path as well.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17975>
With syncFdFencing feature, venus starts forwarding renderer sync_fd
fencing support. The driver side now can track the renderer sync_fd
fencing features. This change adds the initial stubs.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17975>
Now that we don't create fence upon device creation, let's also defer
the feedback pool grow to the first event or non-external fence
creation. This makes venus device creation lighter and is good for CI.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17975>
Sync fd fence export implies a payload reset operation, and application
can immediately do another submission with the same fence after export.
Concurrent use of the same feedback slot is incorrect. Keeping a list of
feedback slots for sync_fd external fence is a bit over designed given
those fences are usually not checked or waited by the app, but will hand
off the ownership via sync fd to an external client.
Fixes: d7f2e6c8d0 ("venus: add fence feedback")
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17975>
Specifying the name at build time, as opposed to renaming after
the build, serves two purposes:
1. The link from Mesa's OpenGL32.dll and (and EGL/GLES) to the
megadriver is done by filename. If using these frontends, the
megadriver can't be renamed afterwards. And Windows doesn't
have very good symlink support, so that's not really an option
either.
2. The symbol (PDB) filename is also embedded in the DLL using the
build-time expected filename. Renaming can produce odd artifacts
while debugging.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7115
Reviewed-by: Bill Kristiansen <billkris@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18239>
It isn't safe to modify the exec mask before the discard block, and the
definition interferes with GFX11 NOP insertion.
Just use s[0:1] instead, since we won't be using it.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18125>
The main issue was the inconsistent use of `unlikely()`, but the macro
also simplifies the code a little bit.
Signed-off-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18086>
The main issue was the inconsistent use of `unlikely()`, but the macro
also simplifies the code a little bit.
Signed-off-by: Eric Engestrom <eric@igalia.com>
Reviewed-by: Juan A. Suarez <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18086>
The extension disrupts assumptions in venus. It gives
vkCreateFooPipelines an additional success code,
VK_PIPELINE_COMPILE_REQUIRED, which allows some pipelines to succeed
creation and others fail.
Tested with 'dEQP-VK.*cache_control*' at vulkan-cts-1.3.3.1.
pass/fail/skip/warn = 15/0/0/3
Warnings were from long pipeline compiles on a full debug build in host
and guest.
See: https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/890
Signed-off-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17847>
It's not sufficient to vk_free() the pipeline. We must also
vn_object_base_fini().
Signed-off-by: Chad Versace <chadversary@chromium.org>
Reviewed-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Ryan Neph <ryanneph@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17847>
