Every barebone arm or aarch64 job depends on these.
When experimenting with CI, this job drags both kernel+rootfs_arm64 and armhf,
even when the latter is not used.
This should speed up development and relieve one instance for about 30 minutes
and overlap between finishing kernel+rootfs_arm64 and armhf jobs per change.
Here are some size stats:
old arm_test 904M (32+64)
new arm64_test 579M (64bit)
new armhf_test 402M (32bit)
---
both ~ 981M (overhead is 81M overall, but never used together so it's only cost "at rest")
Runtime of the arm*_test jobs is ~ 2 minutes.
Acked-by: Martin Roukala <martin.roukala@mupuf.org>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: "Sergi Blanch Torné" <sergi.blanch.torne@collabora.com>
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19550>
It is still marked as a flake (along with other copyteximage cases) on all
these boards, so this will reduce the CI IRC channel noise given that we
actually expect a Pass. I haven't found where exactly in history we went
from generally-fail to generally-pass, but it looks like around Feb 2022.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19912>
static constexpr const 'value' is replaced by static function
in all type_char template specializations
to avoid the following building errors happening with clang 6
/home/utente/pie-x86_kernel/prebuilts/clang/host/linux-x86/clang-4691093/bin/ld.lld: error: undefined symbol: r600::type_char<r600::ExportInstr>::value
>>> referenced by sfn_scheduler.cpp
>>> sfn_sfn_scheduler.cpp.o:(bool r600::BlockSheduler::collect_ready_type<r600::ExportInstr>(std::__1::list<r600::ExportInstr*, std::__1::allocator<r600::ExportInstr*> >&, std::__1::list<r600::ExportInstr*, std::__1::allocator<r600::ExportInstr*> >&)) in archive src/gallium/drivers/r600/libr600.a
...
/home/utente/pie-x86_kernel/prebuilts/clang/host/linux-x86/clang-4691093/bin/ld.lld: error: undefined symbol: r600::type_char<r600::RatInstr>::value
>>> referenced by sfn_scheduler.cpp
>>> sfn_sfn_scheduler.cpp.o:(bool r600::BlockSheduler::collect_ready_type<r600::RatInstr>(std::__1::list<r600::RatInstr*, std::__1::allocator<r600::RatInstr*> >&, std::__1::list<r600::RatInstr*, std::__1::allocator<r600::RatInstr*> >&)) in archive src/gallium/drivers/r600/libr600.a
clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation)
Cc: "22.2" "22.3" mesa-stable
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19873>
If a shader has XFB outputs but the application never enables
streamout in runtime (no buffers bound and no begin/end pair), we
have to disable it in the shader by emitting buffer size as 0. It's
also still needed to remember that the cmdbuf needs GDS/GDS OA BOs,
so move this at pipeline bind time instead.
Cc: 22.3 mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19801>
The NGG streamout lowering pass allocates space for all outputs which
means we have to align our computation. Otherwise, the maximum number
of vertices is incorrect and we end up by reaching the maximum allowed
LDS size. This code could be shared instead of being duplicated but
that's for later.
Fixes some transform feedback tests with Zink and
RADV_PERFTEST=ngg_streamout on GFX10.3.
Cc: 22.3 mesa-stable
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19801>
Commit c2b06e1a38 ("etnaviv: add support for sharing the TS buffer")
introduced a problem similar to the one fixed in 3b3cd51286 ("etnaviv:
fix renderonly check in etna_resource_alloc") in a different code path.
This causes a NULL pointer dereference when the screen is instanciated
on the render node. Fix it in the same way by just checking for a valid
pointer.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19923>
The flush_seqno is only to be used/updated when a dirty tile status has
been written back to the resource. Using it as a marker to trigger a
texture cache invalidation is bogus and not actually needed. When the
texture resource is updated via a mapping or blit the texture cache
invalidation is already triggered by marking the caches as dirty. If the
resource is updated by fragment output, OpenGL explicitly defines the
result of a later texture read as undefined unless a TextureBarrier is
inserted, which also properly triggers the texture cache invalidate.
Also the current check is bogus as it doesn't handle seqno wraparound.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19800>
This fixes a longstanding bug in the interaction between TS and a write
mapping. The write does not update TS regardless of the way the update
is done. Update via etna_copy_resource would just set the target ts_valid
to false without actually writing back any dirty TS to the resource.
Writes via the CPU would update the resource, but keep ts_valid at true
even if the tile status may now not match the actually written tiles of
the resource anymore.
Fix this by writing back a dirty TS to the target resource if needed
before updating the level with the write data. Always invalidate TS,
even when the update is done by the CPU.
Cc: mesa-stable
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19846>
Vinson Lee