Indeed, vertex_buffer was not properly freed.
For instance, this issue is triggered with:
"piglit/bin/fcc-read-after-clear blit rb -auto -fbo"
while setting GALLIUM_REFCNT_LOG=refcnt.log.
Fixes: 8a963d122d ("r300g/swtcl: don't do stuff which is only for HWTCL")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27678>
The commit that switched to the WA framework forgot to update one of
the ifdef section.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: e6e320fc79 ("anv: make Wa_16013994831 to use intel_needs_workaround")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27676>
Take the opportunity to fix the flush of the descriptor buffer surface
when needed. Previously we would only flush it if the shader used one
of the push descriptor.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27504>
There are a couple mistakes here :
- using a bitfield as an index to generate a bitfield...
- in anv_nir_push_desc_ubo_fully_promoted(), confusing binding
table access of the descriptor buffer with actual descriptors
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Fixes: ff91c5ca42 ("anv: add analysis for push descriptor uses and store it in shader cache")
Reviewed-by: Ivan Briano <ivan.briano@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27504>
Fixes the following libarchive error when building with the libarchive wrap subproject:
In file included from ../subprojects/libarchive-3.7.2/libarchive/archive_write_open_memory.c:33:
../subprojects/libarchive-3.7.2/libarchive/archive.h:101:10: fatal error: 'android_lf.h' file not found
This also removes the version suffixes from the .so's that are referenced
in the mesa3d_cross.mk file as those are not present on the Android target.
Signed-off-by: Joshua Ashton <joshua@froggi.es>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27648>
vkCmdPreprocessGeneratedCommandsNV() shouldn't be affected by
conditional rendering. Confirmed with Ricardo after writing some
tests against NVIDIA.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27658>
Preprocess and execute can be executed on different queue families. If
preprocess is executed on GFX and the indirect count optimization is
enabled, this will generate an empty cmdbuf. Expect GPU hangs if this
DGC IB is then executed on ACE.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27658>
according to spec, these should return NONE if the format is
not supported for a given texture target, but mesa was incorrectly
returning a hardcoded value for all cases without checking the driver
instead, check whether the driver can create a texture for a given
format to correctly handle this non-support case
cc: mesa-stable
Reviewed-by: Jesse Natalie <jenatali@microsoft.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27621>
This fixes a VCN performance regression introduced by the new BO fence
tracking mechanism.
VCN can have many queues. The current BO fence tracking mechanism only
supports 1 queue per IP, and there is an interest to use all VCN queues via
VAAPI. This introduces an alternative BO fence tracking mechanism that is
only enabled for VCN, supports unlimited parallel queues, is similar to
the previous system, can co-exist with the current queue system, and has no
negative impact on CPU overhead as long as it's only used by VCN.
Since we want an unlimited number of queues, we can't generate our own
sequence numbers for those queues. Instead, each buffer will have a new
field "alt_fence", which means an alternative fence. This fence is the last
use of that buffer on any VCN queue. If any other queue wants to use that
buffer, it has to insert alt_fence as a dependency, and replace alt_fence
with the new submitted fence, so that it's always equal to the last use.
Only VCN uses and updates alt_fence when an IB is submitted. Other IPs only
use alt_fence as a fence dependency. alt_fence is NULL when VCN isn't used,
so there is no negative impact on CPU overhead in that case.
It uses a C++ template for amdgpu_cs_submit_ib due to different BO loop
bodies between normal queues and VCN. Those loop bodies execute for every
BO, so they shouldn't have extra code for alt_fence if the queue doesn't
update it.
Acked-and-Tested-by: Leo Liu <leo.liu@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27627>
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>
We don't have to spit out warnings for the end users. For compute if we
fail to initialize, we are falling back to render for compute operation,
Anyway end-user applications can query what the engines/queues are
supported based on that they can choose to use a specific queue.
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Acked-By: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27660>
This allows intel-rt to be turned on in cases where we're on x86_64 and
we're building anv, but otherwise default to off, while still giving
users the power to ignore those defaults if they want to.
Because of the use of `feature.disable_if` this bumps the Meson
requirement to 1.1. I can get rid of that, but it just makes for a lot
more code than using the helper methods
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27645>
Left-shifting by 11*8 or 14*8 is undefined. This fixes many
dEQP-VK.query_pool.statistics_query.* failures (but not pre-existing
flakes) for release builds using clang.
Fixes: 48aabaf225 ("radv: do not harcode the pipeline stats mask for query resolves")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27651>
The performance issue is fixed. This adds RADV_DEBUG=nogsfastlaunch2
to disable it in case users still report issues with it.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27636>
This seems to be the root cause of the huge performance issue with
GS_FAST_LAUNCH=2 on RDNA3 dGPUs. Probably a firmware bug, but on dGPUs
only, because on RDNA3 APUs this is just working...
With that GS_FAST_LAUNCH=2 can be re-enabled by default on GFX11.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27636>
For non-sparse usage there is no difference between
DRM_XE_VM_BIND_OP_UNMAP_ALL and DRM_XE_VM_BIND_OP_UNMAP but for sparse
the same bo can be bound to more than one virtual address.
Then in a case like:
img = vkCreateImage()
mem = vkAllocateMemory()
vkQueueBindSparse(img, mem)
vkFreeMemory(mem)
Note that the sparse VMA bind still points to the closed bo(done in
vkFreeMemory()), but with DRM_XE_VM_BIND_OP_UNMAP_ALL all VMAs
over the bos are removed.
Access to a unbound VMA has a defined behavior(page fault) while
access to a bound VMA without backing gem/bo don't have defined
behavior.
Suggested-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27601>
When running on a detached head (eg. checkout of a tag or a specific
commit), there is no active branch, so we can't perform this check; just
skip it and assume the user knows what they're doing.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27578>
