Latest VKCTS main uses way less memory than before, and increasing the
number of deqp instances to 16 seems to work just fine now.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40918>
When recording secondary command buffers with occlusion queries, the
get_vis_results flag could be set for some graphics sub_cmd's job.
Propagate this flag from secondary command buffer graphics sub_cmds to
primary command buffer sub_cmds to ensure occlusion queries in secondary
command buffers being correctly executed.
Fixes: 5c34be4340 ("pvr: Process secondary buffer queries in vkCmdExecuteCommands.")
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40854>
There's a dynarray field inside gfx sub_cmd called sub_query_indices,
which will contain pending query indices for gfx sub_cmds inside a
secondary command buffer. It's expected that when finishing such gfx
sub_cmds, the content of query_indices is going to be moved there.
However the `util_dynarray_append_dynarray()` call is called with wrong
parameter order, thus it's copying sub_query_indices to query_indices
and then immediately wiping query_indices, forgetting all query indices
in such case.
Fix the `util_dynarray_append_dynarray()` call to fix occlusion queries
in secondary command buffers.
Fixes: 8c506c4b03 ("pvr: Use util_dynarray_append_dynarray()")
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40854>
The last sub_cmd in the command buffer could be a graphics one, and when
ending a graphics sub_cmd, the query_indices array will be checked to
know whether a occlusion query starts during this graphics sub_cmd.
Finalize the query_indices array after ending the last sub_cmd,
otherwise the check for query initiation may have a false negative
result.
Fixes the `dEQP-VK.renderpasses.dynamic_rendering.primary_cmd_buff.
random.seed6` test case.
Fixes: 2b1992a000 ("pvr: Implement vkCmdBeginQuery API.")
Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/40854>
Ideally there should be only sysval lowering in the middle.
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>
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>
