We are generally fine with undefs. However, booleans are only allowed to
contain 0/1 but are stored in 16b registers. Undefs may cause such
registers to be uninitialized and contain values other than 0/1. This
especially happens with undef booleans in phi srcs, which are explicitly
left uninitialized. In general, such non-0/1 values don't cause problems
because we mostly use booleans by comparing them to 0. However, they do
cause problems in special cases like `inot(x)` which we lower to `sub(1,
x)` which only works if true==1.
Fixes misrenderings in "Kingdoms of Amalur: Reckoning".
Totals from 12 (0.01% of 176258) affected shaders:
Instrs: 14590 -> 14615 (+0.17%)
CodeSize: 29796 -> 29808 (+0.04%)
NOPs: 3091 -> 3098 (+0.23%); split: -0.03%, +0.26%
MOVs: 735 -> 748 (+1.77%)
(sy)-stall: 4509 -> 4508 (-0.02%)
Cat0: 3471 -> 3483 (+0.35%); split: -0.03%, +0.37%
Cat1: 1257 -> 1270 (+1.03%)
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42051>
Some backends may want to lower some, but not all, undefs.
For example, in ir3, we are generally fine with undefs. However,
booleans are only allowed to contain 0/1 but are stored 16b registers.
Undefs may cause such registers to be uninitialized and contain values
other than 0/1.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42051>
In anv_shader_lower_nir() we call anv_ensure_fp64_shader() only if
device->fp64_nir is set, but the function that sets device->fp64_nir
is anv_ensure_fp64_shader()! That means the only way for
device->fp64_nir to be set is through blorp: if the app does not issue
the blorp shader that uses fp64, then we won't have it.
Change the check to be like the one we have in blorp_compile_fs_brw().
Fixes: 7d3b62e13d ("anv: only load fp64 software shader when needed")
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42100>
The field was never populated (initialized to 0 with a TODO) yet
printed in dump_shader_info(..) and etna_dump_shader(..), giving
the misleading impression that loop counts were tracked. Remove
the field and its consumers.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41560>
This comes from the compiler bindings and lately we get
error[E0659]: `PIPE_FORMAT_R8_UINT` is ambiguous
--> ../src/nouveau/compiler/nak/from_nir.rs:2193:13
|
2193 | PIPE_FORMAT_R8_UINT => MemType::U8,
| ^^^^^^^^^^^^^^^^^^^ ambiguous name
|
= note: ambiguous because of multiple glob imports of a name in the same module
note: `PIPE_FORMAT_R8_UINT` could refer to the constant imported here
--> ../src/nouveau/compiler/nak/from_nir.rs:12:5
|
12 | use nak_bindings::*;
| ^^^^^^^^^^^^^^^
= help: consider adding an explicit import of `PIPE_FORMAT_R8_UINT` to disambiguate
note: `PIPE_FORMAT_R8_UINT` could also refer to the constant imported here
--> ../src/nouveau/compiler/nak/from_nir.rs:14:5
|
14 | use compiler::bindings::*;
| ^^^^^^^^^^^^^^^^^^^^^
= help: consider adding an explicit import of `PIPE_FORMAT_R8_UINT` to disambiguate
Acked-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42109>
In particular if a queue is going to block, a trace may end with
buffered end traces before the queue gets it's next job. So flush
before blocking. (Also on the producer side, since it is easy.)
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42013>
Track events can be buffered in TLS. They should be flushed before a
thread exits, and ideally periodically (ie. before a thread blocks) to
ensure that "end" events are not lost.
Signed-off-by: Rob Clark <rob.clark@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42013>
Compiling with clang produces a -Winitializer-overrides warning:
src/gallium/drivers/radeonsi/si_sdma_copy_image.c:217:17: warning:
initializer overrides prior initialization of this subobject
[-Winitializer-overrides]
The surf_src and surf_dst ac_sdma_surf initializers each set '.bpp = bpp'
twice: once next to the other scalar fields and once again after the
nested '.offset' initializer. The values are identical, so behavior is
unchanged, but the duplicate field initializer is redundant. Drop the
second one.
Fixes: e6e305988c ("ac,radv,radeonsi: merge tiled/linear surfaces into one struct")
Assisted-by: Claude Code (Claude Opus 4.8)
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Reviewed-by: Benjamin Cheng <benjamin.cheng@amd.com>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pelloux@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42068>
In addition to the general predicates, add wrappers to set
and get the SBID, since they are in the extra struct of
each instruction. This is a preparation for adding DPAS.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/41913>
We now require kernel side CPU queue support (introduced via
DRM_V3D_PARAM_SUPPORTS_CPU_QUEUE). If the underlying kernel lacks
this support i.e. is older than kernel 6.8, physical device
initialization will now fail.
With this requirement guaranteed, we can remove the userspace
fallback paths that manually managed and stalled on indirect
CSD dispatches and query resets.
Reviewed-by: Maíra Canal <mcanal@igalia.com>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42087>
After commit 16c96b0e93 ("v3dv: drop single sync kernel interface"), we
no longer use V3DV_QUEUE_ANY. Therefore, drop it and also remove the
legacy comments about single-sync support.
Signed-off-by: Maíra Canal <mcanal@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42119>
They cause random kernel NULL pointer dereferences. Seems pretty
recent but skipping them is definitely more reliable.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42123>
It is possible for isl_mod_info to be NULL if no drm modifier was
given, layout transition on external queue can hit this condition.
Fixes: 11f8f333e2 ("anv: set a private binding when the image is not externally shared")
Signed-off-by: Tapani Pälli <tapani.palli@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42015>
Halt needs to be always in pair. First halt issued will mask off active
channels and second one will basically re-enable those masked off
channels.
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/42067>
