With the advent of software scoreboarding, we emit sync instructions
in various places to synchronize the execution pipelines. This results
in assembly being littered with a bunch of sync.nop instructions. That
means that when you reorder anything in the program, the scoreboarding
changes, and the number of sync.nops can vary wildly - even if the code
isn't really materially better or worse. This makes it hard to use
tools like shader-db or fossil-db on post-Icelake platforms.
For now, exclude sync.nops from the instruction count statistic. One
day we may want to consider improving the software scoreboarding pass
to emit fewer redundant sync.nop instructions, at which point tracking
this as a separate stat might be useful. For now though, it's simply
cluttering and confusing our results.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27701>
The r8152 error detection is now considering any order of the known
patterns to detect variations of the r8152 issues during the test phase.
This includes a small refactoring for eventual new issues.
Additionally, adjusted the timing for setting the `start_time` in
`test_lava_job_submitter.py` to ensure consistency and reliability in
test execution, aligning the start time closer to the job submission
process.
With this fix, the bad state shown in the following job will be
detected:
https://gitlab.freedesktop.org/drm/msm/-/jobs/55033953
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27688>
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>
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>
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>
Kenneth Graunke