Ints and floats do not need to match between VS and FS, some crazy
shaders might write an uint from the VS and read a noperspective float
from the FS. There will be new tests in the conformance tests that
check that too shortly.
Is this a performance regression? yes.
Can we fix this easily? No, we'll need dynamic prolog/epilog linking.
Since maybe_noperspective is almost useless after this fix, the whole
logic has been removed
Signed-off-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40844>
VS does not need to write the position, it can also leave it as
undefined. We agree that there isn't much sense in noperspective
varyings with undefined perspective, but we still do not want to crash.
This does lead to some real crashes if we mistake some int varying to
noperspective (see next commit).
Signed-off-by: Lorenzo Rossi <lorenzo.rossi@collabora.com>
Reviewed-by: Christoph Pillmayer <christoph.pillmayer@arm.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40844>
nir_opt_varyings does this.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40955>
No Foz-DB changes on Navi48.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40955>
This is scalarized later anyway.
No Foz-DB changes.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Acked-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40955>
Only at this point are loads from uninitialized variables lowered to
undef and copy-propagated so that nir_opt_deref's cast-of-undef
optimization works properly.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40799>
ldg.k can copy up to 256 vec4s at once but we currently emit one ldg.k
per vec4. Fix this by using the load size field of ldg.k.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40947>
The load size field starts at b23 instead of b24 and is 8 bits in size.
b23 makes the blob disassembler select between interpreting the load
size as an immediate or a GPR. However, using a GPR doesn't work as the
HW still seems to interpret the field as an immediate. We copy the
blob's behavior here for consistency.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40947>
We assumed a1.x addressing doesn't work. However, it turns out it
actually does work but instead of taking the offset's hight bits from
a1.x and adding an immediate to the low bits, the full offset is stored
in a1.x and the offset is ignored.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40947>
Doing stores first, loads second doesn't work because there can be
chains of store, load, store... .
Use a fixed point approach instead to calculate sizes for all
destinations.
Fixes: 2fd5b8a391 ("pan/bi: Account for MEMMOV in bi_record_sizes")
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40915>
Constlen cannot always be derived from the usage of @const et al. For
example when using ldc.k/ldg.k. Add a @constlen header to explicitly set
it.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40940>
Since we don't set constlen anymore based on static const reg usage,
computerator was broken. Fix this by setting constlen for @const et al.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Fixes: 4e456ebde4 ("ir3/collect_info: remove max_const calculation")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40940>
src/gallium/drivers/zink/zink_instance.c:34:9: warning: variable 'have_moltenvk_layer' set but not used [-Wunused-but-set-variable]
Fixes: 2b4fcf0a06 ("zink: generate instance creation code with a python script")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40910>
Fixes the following building error:
FAILED: src/intel/compiler/jay/libintel_compiler_jay.a.p/jay_assign_flags.c.o
...
In file included from ../src/intel/compiler/jay/jay_assign_flags.c:6:
../src/intel/compiler/jay/jay_builder.h:184:24: error: static_assert expression is not an integral constant expression
static_assert(sizeof(uintptr_t) <= sizeof(uint64_t) &&
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
Fixes: e42e3193 ("intel: add Jay")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40960>
Quad swizzles should always execute with NoMask and group 0.
We skipped initializing the group, and so inherited whatever the state
from the previous instruction was. This led to incorrect behavior if
the previous instruction was SIMD split:
(16) mov.u32 g84<2>, g2 |
(16|M16) mov.u32 g86<2>, g3 |
(32|M16&W) mov.u32 g2, g126.2<4,4,0> | I@1
Oops. The final quad swizzle shouldn't have had M16 set.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40960>
this is subtle, but the relevant igc:
// In case of shooting down of this instruction, we need to add sync to
// preserve the swsb id sync, so that it's safe to clear the dep
if (currInst.hasPredication() ||
(currInst.getExecSize() != dep.getInstruction()->getExecSize()) ||
(currInst.getChannelOffset() != dep.getInstruction()->getChannelOffset()))
needSyncForShootDownInst = true;
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40960>
This appears to cause some sort of prefetching which is causing
page faults for linear textures on the following page after the
texture allocation.
This might be okay for tiled, but for now just disable it.
The test crashing this was to allocate an 800x409 linear 2D texture
which gnome-initial-setup was doing.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/15277
Cc: mesa-stable
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40939>
