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>
Refactor the code into new function vn_create_pipeline_handles().
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>
These would only have worked in GCC and Clang, which so far wasn't an
issue, but let's clean it up anyway.
Cc: mesa-stable
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18190>
There are a bunch of subtle details of how 32-bit sources are
zero-extended to 64-bit, how their swizzles work, how 64-bit
destinations are shrunk to 32-bit, and how those two interact. This
fixes the interactions... mostly.
Fixes umul_high, all such tests should be passing now. Unblocks idiv
lowering that depends on umul_high.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17860>
This works around issue packing 32-bit scalar swizzles zero-extended to
64-bit, seen with the umul_high implementation. I tried for a while
figuring out the root cause (even rewrote a big chunk of disassembler)
but am still a bit lost. Nevertheless this is a safe workaround with no
performance impact (and avoids relying on NIR undefined behaviour to
implement GPU undefined behaviour), so let's do this for now to fix
umul_high.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17860>
This is super unlikely to be freed before use, but let's fix it anyway.
setup_render_state calls set_sampler_views(take_ownership=true), which
means it takes ownership of the sampler view reference and is free to
unreference it, so we can't use sv after setup_render_state.
Fixes: feda6e9c5d - st/mesa: set take_ownership = true in set_sampler_views
Reviewed-by: Brian Paul <brianp@vmware.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17780>
v2: drop the hardcoded inst->mlen=1 (Rohan)
v3: Move back to LOAD/STORE messages (limited to SIMD16 for LSC)
v4: Also use 4 GRFs transpose loads for fills (Curro)
v5: Reduce amount of needed register to build per lane offsets (Curro)
Drop some now useless SIMD32 code
Unify unspill code
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17555>
With the following SEND instruction :
send(1) nullUD nullUD g0UD 0x4200c504 a0.1<0>UD
This instruction although valid but somewhat nonsensical (SEND message
to write at offset contained in NULL register), triggers an error in
the validator.
The restriction is that we cannot have overlapping sources. The
validator not checking the type of register incorrectly thinks that
the null register (offset 0) is the same as g0.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17555>
We're now able to load up to 8 GRFs in one send.
v2: Switch to use transpose + vector of up to 64 (Thanks Curro!)
v3: Increase parallelism by not reusing the same register for push
constant offset (Curro)
v4: Drop dead ADD() instruction (Curro)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17555>
This fixes the use of an uninitialzed value:
Conditional jump or move depends on uninitialised value(s)
bcmp (vg_replace_strmem.c:1203)
_mesa_add_sized_state_reference (prog_parameter.c:434)
st_nir_assign_uniform_locations(gl_context*, gl_program*, nir_shader*) (st_glsl_to_nir.cpp:209)
st_finalize_nir (st_glsl_to_nir.cpp:1041)
by 0x58271B9: st_glsl_to_nir_post_opts(st_context*, gl_program*, gl_shader_program*) (st_glsl_to_nir.cpp:571)
...
Uninitialised value was created by a heap allocation
malloc (vg_replace_malloc.c:381)
ralloc_size (ralloc.c:114)
ralloc_array_size (ralloc.c:218)
deref_offset_var (nir_lower_atomics_to_ssbo.c:47)
lower_instr (nir_lower_atomics_to_ssbo.c:111)
nir_lower_atomics_to_ssbo (nir_lower_atomics_to_ssbo.c:204)
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18227>
