Iris in general doesn't really like checking the return value of its
allocations, but in some places it does assert that those pointers are
non-NULL. We've recently investigated a bug that could have been
coming from a failed bo->deps realloc(), so add the assert() here to
help give us more confidence over things the next time we're debugging
issues.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
(cherry picked from commit 7c538b5ad8)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25404>
Keep most cases using the stack as it's cheaper, but fall back to the
heap when the size gets too big.
This should fix a stack overflow reported by @rhezashan for a case
where we had lots of iris_screens.
Credits to Matt Turner and José Roberto de Souza for their work on
this issue, which led us to find its root cause.
Cc: mesa-stable
Reported-by: rheza shandikri (@rhezashan in gitlab)
Credits-to: José Roberto de Souza <jose.souza@intel.com>
Credits-to: Matt Turner <mattst88@gmail.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
(cherry picked from commit 3cec15dd14)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25404>
This is the only place that touches bo->deps but does not explicitly
lock it and is not a setup/teardown function where locking won't help
anything.
I'm confident we won't hit this assertion, but I've recently had this
lock as the suspect of a bug and had to check the callers to see if we
could be calling from any unlocked place. Having the assert helps
increasing our confidence.
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
(cherry picked from commit 762b9aad01)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25404>
This is a modified version of a commit originally in !7698. This version
add the changes to brw_fs_copy_propagation. If the address passed to
fs_visitor::swizzle_nir_scratch_addr is a constant, that function will
generate SHL with two constant sources.
DG2 uses a different path to generate those addresses, so the constant
folding can't occur there yet. That will be addressed in the next
commit.
What follows is the commit change history from that older MR.
v2: Previously this commit was after `intel/fs: Combine constants for
integer instructions too`. However, this commit can create invalid
instructions that are only cleaned up by `intel/fs: Combine constants
for integer instructions too`. That would potentially affect the
shader-db results of each commit, but I did not collect new data for
the reordering.
v3: Fix masking for W/UW and for Q/UQ types. Add an assertion for
!saturate. Both suggested by Ken. Also add an assertion that B/UB types
don't matically come back.
v4: Fix sources count. See also ed3c2f73db ("intel/fs: fixup sources
number from opt_algebraic").
v5: Fix typo in comment added in v3. Noticed by Marcin. Fix a typo in a
comment added when pulling this commit out of !7698. Noticed by Ken.
shader-db results:
DG2
No changes.
Tiger Lake, Ice Lake, and Skylake had similar results (Ice Lake shown)
total instructions in shared programs: 20655696 -> 20651648 (-0.02%)
instructions in affected programs: 23125 -> 19077 (-17.50%)
helped: 7 / HURT: 0
total cycles in shared programs: 858436639 -> 858407749 (<.01%)
cycles in affected programs: 8990532 -> 8961642 (-0.32%)
helped: 7 / HURT: 0
Broadwell and Haswell had similar results. (Broadwell shown)
total instructions in shared programs: 18500780 -> 18496630 (-0.02%)
instructions in affected programs: 24715 -> 20565 (-16.79%)
helped: 7 / HURT: 0
total cycles in shared programs: 946100660 -> 946087688 (<.01%)
cycles in affected programs: 5838252 -> 5825280 (-0.22%)
helped: 7 / HURT: 0
total spills in shared programs: 17588 -> 17572 (-0.09%)
spills in affected programs: 1206 -> 1190 (-1.33%)
helped: 2 / HURT: 0
total fills in shared programs: 25192 -> 25156 (-0.14%)
fills in affected programs: 156 -> 120 (-23.08%)
helped: 2 / HURT: 0
No shader-db changes on any older Intel platforms.
fossil-db results:
DG2
Totals:
Instrs: 197780415 -> 197780372 (-0.00%); split: -0.00%, +0.00%
Cycles: 14066412266 -> 14066410782 (-0.00%); split: -0.00%, +0.00%
Totals from 16 (0.00% of 668055) affected shaders:
Instrs: 16420 -> 16377 (-0.26%); split: -0.43%, +0.17%
Cycles: 220133 -> 218649 (-0.67%); split: -0.69%, +0.01%
Tiger Lake, Ice Lake and Skylake had similar results. (Ice Lake shown)
Totals:
Instrs: 153425977 -> 153423678 (-0.00%)
Cycles: 14747928947 -> 14747929547 (+0.00%); split: -0.00%, +0.00%
Subgroup size: 8535968 -> 8535976 (+0.00%)
Send messages: 7697606 -> 7697607 (+0.00%)
Scratch Memory Size: 4380672 -> 4381696 (+0.02%)
Totals from 6 (0.00% of 662749) affected shaders:
Instrs: 13893 -> 11594 (-16.55%)
Cycles: 5386074 -> 5386674 (+0.01%); split: -0.42%, +0.43%
Subgroup size: 80 -> 88 (+10.00%)
Send messages: 675 -> 676 (+0.15%)
Scratch Memory Size: 91136 -> 92160 (+1.12%)
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 61c786bad5)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25377>
opt_copy_propagation can create invalid instructions like
shl(8) vgrf96:UD, 2d, 8u
These instructions will be cleaned up by opt_algebraic. The irony is
opt_algebraic converts these to simple mov instructions that
opt_copy_propagation should clean up. I don't think we want a loop like
do {
progress = false;
if (OPT(opt_copy_propagation)) {
OPT(opt_algebraic);
OPT(dead_code_eliminate);
}
} while (progress);
But maybe we do?
Maybe this would be sufficient:
while (OPT(opt_copy_propagation))
OPT(opt_algebraic);
OPT(dead_code_eliminate);
No shader-db or fossil-db changes (yet) on any Intel platform. This is
expected.
v2: Do opt_algebraic immediately after every call to
opt_copy_propagation instead of being clever. Suggested by Lionel.
Tested-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
(cherry picked from commit 56e6186dcf)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25377>
This reverts commit 6b494745be.
The logic is not entirely correct: the comparison is between two
static-analysis estimates of a dynamic system with variables that aren't
captured by the shader source, so using ">" will always have greater potential
to cause regressions whenever the performance difference between the two builds
is something not captured by the static model, no matter how much the model is
improved.
Reference: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9262
(cherry picked from commit d142c845d0)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25377>
Before this patch, when updating the indirect clear color, BLORP only
invalidated the texture cache on gfx11. The hardware docs state that
the texture cache invalidation is also needed on gfx12 however. Add
this invalidation for gfx12 and move the fast-clear related cache
invalidations to the drivers for clarity and performance.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5850
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
(cherry picked from commit 87149cc545)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25377>
fossil-db (navi31):
Totals from 279 (0.35% of 79332) affected shaders:
(no stat changes)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Fixes: c778803d67 ("aco/assembler: change prefetch mode on GFX10.3+ during loops if beneficial")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25312>
(cherry picked from commit 21db2e7017)
Move setting the default values from getEncParamPresetH264/5 as this
function is called on each frame which would result in overwriting
values set by application.
This fixes setting HRD parameters and max_qp/min_qp when
PIPE_VIDEO_CAP_ENC_QUALITY_LEVEL is not supported.
Cc: mesa-stable
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25355>
(cherry picked from commit dd2ef9a0e4)
The encoder is created in handleVAEncSequenceParameterBufferType and it
also sets some default parameters, so we need to make sure to handle
this buffer first because application may have already set those
parameters from earlier buffers.
This fixes setting HRD parameters with gstreamer vah264enc/vah265enc
when PIPE_VIDEO_CAP_ENC_QUALITY_LEVEL is supported.
Cc: mesa-stable
Reviewed-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25355>
(cherry picked from commit c970a9b663)
The index at which the dynamic descriptor offsets were being
stored was incorrect, leading to some offsets not being stored and
thus `0` being applied as the offset to the descriptors instead.
dEQP test fixed:
dEQP-VK.binding_model.shader_access.{primary,secondary}_cmd_buf
.uniform_buffer_dynamic
.{vertex,fragment,compute,vertex_fragment}
.multiple_discontiguous_descriptor_sets
.*_descriptor.offset_view_{,non}zero_dynamic_nonzero
Fixes: aa791961a8 ("pvr: Add support for dynamic buffers descriptors")
Signed-off-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25320>
(cherry picked from commit feafb8a256)
The `i` iteration variable was being used instead of `k` when
appending new mappings, and getting the current source rect.
dEQP test fixed:
dEQP-VK.pipeline.monolithic.image.suballocation.sampling_type
.combined.view_type.3d.format.*.count_1.
.{3x3x3,5x5x5,...(odd dimensions)}
Fixes: 060c3db4ef ("pvr: Complete pvr_generate_custom_mapping()")
Reported-by: James Glanville <james.glanville@imgtec.com>
Signed-off-by: Karmjit Mahil <Karmjit.Mahil@imgtec.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25321>
(cherry picked from commit bf17e4fe33)
wayland surfaces are likely to become unlinked in WSI implementations upon
retiring a swapchain, requiring the pending present to complete
in order to avoid invalid access
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25288>
(cherry picked from commit aaabb5b0f2)
tex->cmask_base_address_reg and tex->cb_color_info are used in
si_emit_framebuffer_state so we have to re-emit the state when
they're modified.
It's not done in si_alloc_separate_cmask because it cannot
update framebuffer.dirty_cbufs.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9830
Cc: mesa-stable
Reviewed-by: Yogesh Mohan Marimuthu <yogesh.mohanmarimuthu@amd.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25317>
(cherry picked from commit 60a7c9688c)
An AHB backing a Vkbuffer requires AHARDWAREBUFFER_USAGE_GPU_DATA_BUFFER
usage bit, which is missed from the original ANV and RADV Android
frontends as well as the common VK Android refactor.
Cc: mesa-stable
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Chia-I Wu <olvaffe@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25263>
(cherry picked from commit cd0b86fce1)
I don't see why a p_logical_end is expected or required. It might not be
present in some situations, which causes an assertion failure:
s2: %19646:s[0-1] = p_reload %19701:v[8], 11
s2: %0:exec, s1: %8817:scc = s_andn2_b64 %19646:s[0-1], %0:exec
s2: %8818:s[20-21] = p_cbranch_z %0:exec BB1116, BB1114
No fossil-db changes (gfx1100).
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25244>
(cherry picked from commit 6dd751b3b9)
This is when the copies actually happen, not at the branch.
fossil-db (gfx1100):
Totals from 1 (0.00% of 79332) affected shaders:
Instrs: 424 -> 423 (-0.24%)
CodeSize: 2172 -> 2168 (-0.18%)
Latency: 2899 -> 2896 (-0.10%)
Copies: 24 -> 23 (-4.17%)
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25244>
(cherry picked from commit 8d5bd3ca48)
Fixes crash for
dEQP-VK.mesh_shader.ext.in_out.with_f16.permutation_0.mesh_only and
similar tests on GFX11.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Fixes: 3d29779a25 ("aco/optimizer_postRA: Distinguish overwritten untrackable and subdword.")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25223>
(cherry picked from commit ac48334ecd)
When building for Android, avoid the LLVM dependency if possible.
Cc: mesa-stable
Acked-by: Mauro Rossi <issor.oruam@gmail.com>
Reviewed-by: Roman Stratiienko <r.stratiienko@gmail.com>
Change-Id: Idda03f954b4b5326e23a848e541411b60fcef063
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24007>
(cherry picked from commit 497aecb210)
The AMD Vulkan driver uses LLVM by default, but it is possible to build
the driver without the LLVM dependency. In this case, we must explicitly
disable LLVM support, or else meson will die after failing to find LLVM.
The Android build system already knows when to link libLLVM, so forward
that information to meson.
Cc: mesa-stable
Acked-by: Mauro Rossi <issor.oruam@gmail.com>
Reviewed-by: Roman Stratiienko <r.stratiienko@gmail.com>
Change-Id: I7489d3811625b390aaaf2e84e666b4a8d98328b0
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24007>
(cherry picked from commit ec32619cb0)
Android bundles ANGLE for implementing OpenGL ES and EGL on top of
Vulkan. When using ANGLE, mesa is only needed for its Vulkan drivers.
Cc: mesa-stable
Acked-by: Mauro Rossi <issor.oruam@gmail.com>
Reviewed-by: Roman Stratiienko <r.stratiienko@gmail.com>
Change-Id: I034a0af52f9216bc5f1322f584bc591c90222327
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24007>
(cherry picked from commit 599f47f11c)
Making the sub_cs not writeable switches the BO we're emitting to, which
causes an assert failure in tu_cs_end_sub_stream() because it looks like
we have a mismatched start/end. Just make it not writeable later.
Fixes: 97da0a7734 ("tu: Rewrite to use common Vulkan dynamic state")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25225>
(cherry picked from commit 64ed357699)
this function doesn't use the correct tc map flags, which causes
drivers to (potentially) use the wrong slab for transfer allocation
and then crash
Fixes: 51ad269198 ("aux/tc: handle stride mismatch during rp-optimized subdata")
Acked-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25227>
(cherry picked from commit a5be0385c7)
if a set_framebuffer_state call has occurred but no draws have been
triggered, the rp info must be preserved for the driver to (eventually)
use after the sync
Fixes: 07017aa137 ("util/tc: implement renderpass tracking")
Acked-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25227>
(cherry picked from commit 81dd39de01)
problem: max_poc means the number of bits used in poc lsb
in slice header, and it should not be related to GOP
size. When large GOP size used, it could generate
corrupted video, as the POC could not be correctly
decoded.
solution: use fixed value of max_poc (16) for now.
Cc: mesa-stable
Reviewed-by: Boyuan Zhang <Boyuan.Zhang@amd.com>
Signed-off-by: Ruijing Dong <ruijing.dong@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25214>
(cherry picked from commit fb0f51bc64)
