Funny story... this is how regular b2f was implemented before Curro
implmented the `MOV dst:F -src:D` method 9 years ago (see
3ee2daf23d).
Eliminating the type conversion in the arithmetic operation enables the
next commit.
No shader-db or fossil-db changes on any Intel platform.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33931>
This commit prevents code quality regressions in the next
commit. Without this, some fragment shaders in Batman: Arkham Origins
have code like:
shr(8) g51<1>UW g1.28<1,8,0>UB 0x76543210V
...
and(8) g52<1>UD ~g51<8,8,1>UW 0x0001UW
...
add(8) g56<1>D -g52<8,8,1>D 1D
transformed to
shr(8) g51<1>UW g1.28<1,8,0>UB 0x76543210V
...
and(8) g52<1>UD ~g51<8,8,1>UW 0x0001UW
...
mov(8) g56<1>D -g52<8,8,1>D
...
and(8) g57<1>UD ~g56<8,8,1>D 0x00000001UD
Propagating through the negation allows the added MOV to be deleted.
shader-db:
All Intel platforms had simlar results. (Lunar Lake shown)
total instructions in shared programs: 16968020 -> 16968019 (<.01%)
instructions in affected programs: 281 -> 280 (-0.36%)
helped: 1 / HURT: 0
total cycles in shared programs: 914598850 -> 914598832 (<.01%)
cycles in affected programs: 5398 -> 5380 (-0.33%)
helped: 1 / HURT: 0
A single Blender vertex shader was affected.
fossil-db:
Lunar Lake, Tiger Lake, Ice Lake, and Skylake had similar results. (Lunar Lake shown)
Totals:
Instrs: 209894650 -> 209894651 (+0.00%)
Cycle count: 30545958586 -> 30545952860 (-0.00%)
Totals from 2 (0.00% of 706657) affected shaders:
Instrs: 3582 -> 3583 (+0.03%)
Cycle count: 1875100 -> 1869374 (-0.31%)
Meteor Lake and DG2 had similar results. (Meteor Lake shown)
Totals:
Subgroup size: 9906400 -> 9906416 (+0.00%)
Totals from 2 (0.00% of 805770) affected shaders:
Subgroup size: 16 -> 32 (+100.00%)
Two compute shaders in Hogwarts Legacy were affected.
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33931>
This is mostly defensive. If a convergent value ever ended up as a
source of a DDX or DDY, the eu_emit code will ignore the stride. This
will result in bad code being generated.
No shader-db or fossil-db changes on any Intel platform.
v2: DDX and DDY will always be float, but brw_imm_for_type only works
with integer types.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Suggested-by: Ken
Fixes: d5d7ae22ae ("brw/nir: Fix up handling of sources that might be convergent vectors")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33007>
The vast majority of the callers want channel = 0. During the
development process, using this default parameter value saved a lot of
pain in rebasing. However, it seems to be more trouble than it's worth.
Issue #12464 occurred because LNL was merged while this code was in
review. As a result, one caller of get_nir_src that wanted channel = -1
was not inspected closely, and it got the default channel = 0 instead.
To prevent this happening in the future (with possible branches still
yet to be merged, for example), remove the default parameter. This will
force the inspection of any callers that don't have an explicit channel
parameter. Hopefully that will prevent more problems.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33007>
The source of nir_intrinsic_load_barycentric_at_offset is a vector, so
-1 should be passed to get_nir_src. This is also done for texture
sampling intrinsics.
I skimmed the other user of get_nir_src, and I believe they are
correct. This one was just missed as LNL support landed an many, many
rebases of the original MR occurred.
v2: Fix another get_nir_src call. Suggested by Lionel.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [v1]
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Fixes: d5d7ae22ae ("brw/nir: Fix up handling of sources that might be convergent vectors")
Closes: #12464
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33007>
Bifrost keeps a cache of information about buffers being
used as indices. Unfortunately, it was not keeping information
about the size of the indices (probably because this rarely
changes). If a program deliberately re-interprets the indices
as a different type (e.g. UNSIGNED_INT instead of UNSIGNED_SHORT)
then we will use incorrect values from the cache. This actually
showed up in a test program we were running.
Fix by saving the index size in the cache key.
Cc: mesa-stable
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34011>
This issue seems to be specific to textureGather() which could
fail when processing some surfaces. These surfaces are configured
with non-standard one and zero swizzles. The gpu doesn't support
this very specific setup with all the possible hardware formats.
This change selects a compatible configuration when this is
possible.
This change was tested on palm, barts and cayman. This change
fixes the 216 remaining arb_texture_gather tests:
spec/arb_texture_gather/texturegather/.*-zero-.*: fail pass
spec/arb_texture_gather/texturegather/.*-one-.*: fail pass
spec/arb_texture_gather/texturegatheroffset/.*-zero-.*: fail pass
spec/arb_texture_gather/texturegatheroffset/.*-one-.*: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Acked-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34293>
After ca09c173f6, util_blitter_clear_render_target() requires
a call to util_blitter_save_fragment_constant_buffer_slot().
The r600 implementation was using the same sequence with
util_blitter_clear_depth_stencil() which does not need this
call. This was the cause of the refcnt imbalance.
For instance, this issue is triggered with:
"piglit/bin/ext_clear_texture-stencil -auto -fbo"
while setting GALLIUM_REFCNT_LOG=refcnt.log.
Fixes: ca09c173f6 ("gallium/u_blitter: remove UTIL_BLITTER_ATTRIB_COLOR, use a constant buffer")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34292>
The vtn_ssa_value for a cmat is not backed by a nir_def, but by a nir_variable, so
can't be used directly when calling a function. In most cases the cmat is used by
reference so code will take the value of deref for it (which is a `nir_def`).
When passing a cooperative matrix to a function by value, let the caller pass the deref
value, and the callee copy to a new local variable from that deref.
Fixes: b98f87612b ("spirv: Implement SPV_KHR_cooperative_matrix")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34364>
The cid loop in the previous implementation stopped at n_counters for a
given category, even though cid is a global id that does not start
counting from zero at the beginning of each category. As a result, we
missed most of the counters outside of the first category.
Signed-off-by: Benjamin Lee <benjamin.lee@collabora.com>
Fixes: 513d1baaea ("pps: Panfrost pps driver")
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34202>
Marek Olšák