With new S3 support, we can use JWT-only server interaction via the
removal of `role-session` and `minio-host` arguments from PIGLIT_ARGS in
YAML.
This parameter change will come in a later commit.
Solved Conflicts:
.gitlab-ci/container/build-piglit.sh
.gitlab-ci/image-tags.yml
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
(cherry picked from commit 70ce1dcacc92a816322082c8695569b6a91a1810)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19604>
The rootfs generation is failing due to issues with the deqp and crosvm
build stages.
== crosvm ==
This week, crates.io released the bindgen cargo package at version
0.61.0, but this version could not be installed via `cargo install
bindgen ...`, setting the version to the previous one to avoid breaking
the Mesa rootfs builds.
See also related failed job:
https://gitlab.freedesktop.org/gallo/mesa/-/jobs/30046963
== deqp ==
The deqp build is failing due to the missing archive of an old zlib
release version, which was deleted due to a CVE, see zlib 1.2.13 release
notes.
As the deqp uprev to 1.3.4.0, which contains the fix, was not
straightforward, let's only apply the necessary patch to fix zlib
source code download link and then remove this indirection in an
eventual deqp uprev.
Example of a failed kernel+rootfs build job:
https://gitlab.freedesktop.org/gallo/mesa/-/jobs/30045324
Solved Conflicts:
.gitlab-ci/image-tags.yml
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Reviewed-by: Yonggang Luo <luoyonggang@gmail.com>
(cherry picked from commit db2c14887bb52ec6fd05c5f8b5363f1689b4b45c)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19604>
Stick to macos-11 to prevent accident broken
always install meson with pip to prevent pull new version of python
Cc: mesa-stable
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com>
Acked-by: Eric Engestrom <eric@igalia.com>
Acked-by: Dylan Baker <dylan.c.baker@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19640>
While Panfrost allocates linear images with strides that are a multiple of 64
bytes, other dma-buf producers on the system may not satisfy this requirement.
However, at least on v7 and newer, any image with a regular format must have a
stride that is a multiple of 64 bytes.
This fixes a real bug in an application that created a linear R8_UNORM image
with stride 480 bytes, imported it as an EGL_image, and then tried to texture
from it with the GPU. Previously, the driver allowed this situation but it
resulted in an imprecise fault from the GPU. This patch corrects the driver to
reject the import as invalid due to the unaligned stride, ensuring we never
attempt to texture from such a resource.
To implement, we add some new layout queries to centralize knowledge about the
stride alignment requirements, and we sprinkle in asserts to show how the
invariant is upheld throughout the lifecycle of image creation to texturing.
Cc: mesa-stable
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19620>
(cherry picked from commit 811f8a19469722bea32f3c539b8cf0939fe3b057)
This can cause us to stomp the contents of r5 before we have a chance to read
it, like this:
0x3d103186bb800000 nop ; nop ; ldvary.r0
0x3d105686bbf40000 nop ; mov rf26, r5 ; ldvary.r1
0x020000ef0000d000 bu.allna 232, r:unif (0x0000001c / 0.000000)
0x3d1096c6bbf40000 nop ; mov rf27, r5 ; ldvary.r2
Here, the MOV in the last instruction is supposed to read r5 produced from
ldvary.r0, but because we have inserted the bu instruction in between now
that read happens at the same time that ldvary.r1 updates r5, stomping the
value we were supposed to read.
Fix this by disallowing injection of a branch instruction in between an ldvary
instruction and its write to the r5 register 2 instructions later.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7062
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19616>
(cherry picked from commit 1174f376096ed6ceebb0fb2810456f1501a68df7)
If the map doesn't set MAP_DISCARD_RANGE, we do have to copy the existing
contents over. MAP_WRITE on its only gives permission to replace the contents,
unfortunately it does not require that the application actually do so.
Closes: #7640
Fixes: 0b26a9f7739 ("panfrost: Don't copy resources if replaced")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reported-by: Roman Elshin
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19576>
(cherry picked from commit cf7a3906b0629b2b6aadd3b18a39eae06b10fd6a)
Fixes issue with "is helper invocation" that in recent SPIR-V is mapped to
a volatile Load. The CSE was catching the loads before they were transformed
in the new is_helper_invocation intrinsic (that is not reorderable).
Fixes: 729df14e45 ("nir: Handle volatile semantics for loading HelperInvocation builtin")
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: M Henning <drawoc@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19432>
(cherry picked from commit 8ab628ab2e4d4f460e2eabdb11876997c0ab13bc)
Don't copy propagate the constant in situations like
mov(8) g8<1>D 0x7fffffffD
mul(8) g16<1>D g8<8,8,1>D g15<16,8,2>W
On platforms that only have a 32x16 multiplier, this will result in
lowering the multiply to
mul(8) g15<1>D g14<8,8,1>D 0xffffUW
mul(8) g16<1>D g14<8,8,1>D 0x7fffUW
add(8) g15.1<2>UW g15.1<16,8,2>UW g16<16,8,2>UW
On Gfx8 and Gfx9, which have the full 32x32 multiplier, it results in
mul(8) g16<1>D g15<16,8,2>W 0x7fffffffD
Volume 2a of the Skylake PRM says:
When multiplying a DW and any lower precision integer, the
DW operand must on src0.
See also https://gitlab.freedesktop.org/mesa/crucible/-/merge_requests/104.
Previous to INTEL_shader_integer_functions2 (in Vulkan or OpenGL), I
don't think it would be possible to create a situation where this could
occur. I discovered this via some optimizations that can determine that
the non-constant source must be able to fit in 16-bits. The case listed
above came from piglit's "ext_transform_feedback-order arrays points"
with those optimizations in place.
No shader-db or fossil-db changes on any Intel platform.
Fixes: de6c0f8487 ("intel/fs: Implement support for NIR opcodes for INTEL_shader_integer_functions2")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17718>
(cherry picked from commit db204121686726c74dd0aba2d1c1790d40e7baba)
This patch filters-out '-std=gnu++14' from the cflags obtained
from AOSP/KATI dummy target output to avoid the following building errors:
FAILED: src/gallium/drivers/r600/45f68e3@@r600@sta/sfn_sfn_assembler.cpp.o
...
clang++ ... -std=c++17 ... -std=gnu++14
...
In file included from ../src/gallium/drivers/r600/sfn/sfn_assembler.cpp:27:
In file included from ../src/gallium/drivers/r600/sfn/sfn_assembler.h:32:
In file included from ../src/gallium/drivers/r600/sfn/sfn_shader.h:31:
../src/gallium/drivers/r600/sfn/sfn_instr.h:369:56: error: no template named 'is_base_of_v' in namespace 'std'; did you mean 'is_base_of'?
template <typename T, typename = std::enable_if_t<std::is_base_of_v<Instr, T>>>
~~~~~^~~~~~~~~~~~
is_base_of
/home/utente/pie-x86_kernel/external/libcxx/include/type_traits:1412:29: note: 'is_base_of' declared here
struct _LIBCPP_TEMPLATE_VIS is_base_of
^
In file included from ../src/gallium/drivers/r600/sfn/sfn_assembler.cpp:27:
In file included from ../src/gallium/drivers/r600/sfn/sfn_assembler.h:32:
In file included from ../src/gallium/drivers/r600/sfn/sfn_shader.h:31:
../src/gallium/drivers/r600/sfn/sfn_instr.h:369:51: error: template argument for non-type template parameter must be an expression
template <typename T, typename = std::enable_if_t<std::is_base_of_v<Instr, T>>>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/utente/pie-x86_kernel/external/libcxx/include/type_traits:439:16: note: template parameter is declared here
template <bool _Bp, class _Tp = void> using enable_if_t = typename enable_if<_Bp, _Tp>::type;
^
2 errors generated.
Cc: "22.2" "22.3" mesa-stable
Reviewed-by: Roman Stratiienko <r.stratiienko@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19563>
(cherry picked from commit fd8ec189e575d5220d8b4c30647fa6de57928e07)
While the GC880 is HALTI0, it still uses the old set of state registers
for PE pipe configuration. This is another specialty of the GC880, readd
the missing handling for this GPU otherwise e.g. Qt5 cube example suffers
from rendering corruption with both eglfs and wayland backends.
Fixes: 7c46a48836 ("etnaviv: use new PE pipe address states on >= HALTI0")
Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Marek Vasut <marex@denx.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19562>
(cherry picked from commit 20984aab0f6717f5fbf79fc21c2c5f442472b605)
Currently float16 to int64 conversions don't work correctly, because
the "div" variable has an infinite value, since 2^32 isn't
representable as a 16-bit float, which causes the result of of rem(x,
div) to be NaN for all inputs, leading to an incorrect result. Since
no values of magnitude greater than 2^32 are representable as a
float16 we don't actually need to do the fdiv/frem operations, the
conversion is equivalent to f2u32 with the result padded to 64 bits.
Rework:
* Jordan: Handle f16 in if/else rather than conditional
Fixes: 936c58c8fc ("nir: Extend nir_lower_int64() to support i2f/f2i lowering")
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19391>
(cherry picked from commit e14f85366ebbc57f45d2561e0d3f0804f8adb549)
`pred` is a pointer, for sufficiently large numbers these
being cast to int were both > 0 regardless of the order
of `data1` and `data2`.
Fixes: 523a28d3fe ("nir: add an instruction set API")
Reviewed-by: Jason Ekstrand <jason.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19539>
(cherry picked from commit c987a727a76eda1feada07e2eca6a5597dbddd93)
These leaks on device creation failure have been there before, but
were only exposed as CTS failures after the recent event refactoring.
Partially fixes:
dEQP-VK.api.device_init.create_instance_device_intentional_alloc_fail.basic
dEQP-VK.api.object_management.alloc_callback_fail.device
dEQP-VK.api.object_management.alloc_callback_fail.device_group
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Eric Engestrom <eric@igalia.com>
cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19458>
(cherry picked from commit b78fd50e90c700466213e4b3b40ce10547b1e14e)
Copied wrong from radeonsi. The registers following the scratch
buffer address are the shader rsrc1/rsrc2. Not the user SGPR0
containing the ring resource word 1.
Fixes: 278e533ec9 ("radv: update scratch buffer registers on GFX11")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19488>
(cherry picked from commit b8865ad04643cd7e8faa8a863d81fedbc1e29231)
The entire point of resource shadowing is to avoid unnecessary flushing.
Flushing readers after shadowing is counterproductive. A refresher on
how resource shadowing is supposed to work:
First, we determine if it's beneficial to shadow resources. If so, we
create a new backing buffer object. We flush the current writer of the
resource, if there is one, so the current contents become known to the
CPU. If we are not discarding the original resource, we then copy the
existing contents of the buffer to the new shadow buffer on the CPU.
Finally, we swap the resource's backing buffer for our shadow. Any batch
that reads the resource will continue to read the old copy of the
resource, and any future draw calls will see the new copy with the
change implemented.
Where did we go wrong?
In 988d5aae74 ("panfrost: Flush resources when shadowing"), we started
flushing all readers. We didn't actually need to flush, we just needed
to avoid dangling references on the batches reading the old copy of the
resource. But that's easily enough avoided: just remove the references.
The batches still hold a reference to the underlying BO, which will be
freed at the right time regardless.
Originally motivated by glmark2 -bbuffer:update-method=subdata, which
has some pathological access paterns.
Firefox is a lot faster anecdotally (now scrolling at 60fps in firefox).
But what actually motivated this is an apitrace from Duckstation's GLES
renderer. With this patch, the in-game portion is improved 3fps to 21fps.
Closes: #4028
Fixes: 988d5aae74 ("panfrost: Flush resources when shadowing")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19361>
(cherry picked from commit 2d8f28df731638e1270b0ae273c7bfd2b29b7993)
If a synchronized transfer_map is going to overwrite an entire resource,
there's no need to memcpy in the original contents ahead-of-time. This
memcpy is particularly bad for large buffers where it's copying WC->WC,
although that could be mitigated with threaded_context's cpu_storage in
the future if needed.
Prevents a performance regression in glmark2's buffer scenes from the
next patch, hence the Cc.
Cc: mesa-stable
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19361>
(cherry picked from commit 0b26a9f773956fc00a77b0d4a7aafee5795ce935)
To match PIPE_COMPUTE_CAP_MAX_THREADS_PER_BLOCK, having it be higher in any
dimension is nonsensical and can confuse apps. Fixes tests in
KHR-GLES31.core.texture_buffer.* on Mali-T860.
Fixes: 9b19104a30b ("pan/mdg: Lower PIPE_COMPUTE_CAP_MAX_THREADS_PER_BLOCK on Midgard")
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19238>
(cherry picked from commit 027ee6c9e9c20033d0afb3c65684573f286072c7)
Now we're back to a single XFB implementation for all gens. Fixes:
KHR-GLES31.core.draw_indirect.advanced-twoPasses-transformFeedback-arrays
KHR-GLES31.core.draw_indirect.advanced-twoPasses-transformFeedback-elements
Cc: mesa-stable
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19238>
(cherry picked from commit 0955fe8fe20d2ffb416394be80a12897d7a6d61c)
rc_adjust_channels is inteded for moving the swizzles to a new channels
when rewriting the writemask of an instruction. However for readers one
needs to keep the swizzles in the old channels but rather convert to the
new values, so use the proper helper rc_rewrite_swizzle.
With the new swizzle fixed, we should properly detect that it would be
invalid and thus we can select the proper register class to prevent the
writemask rewrite in the regalloc.
Documentation was added to rc_adjust_channels to make it more clear what
it actually does.
Fixes a bunch of dEQP tests.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7521
Signed-off-by: Pavel Ondračka <pavel.ondracka@gmail.com>
Reviewed-by: Filip Gawin <filip@gawin.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19158>
(cherry picked from commit 1e9e5618110542550b9f92dca8392f213bfd46b7)
Conflicts:
src/gallium/drivers/r300/ci/r300-r480-fails.txt
WFI is not a strong enough barrier, which shows up in piglit qbo tests
which do a single draw.
Fixes: 13fc03f4c0 ("freedreno/a6xx: Avoid stalling for occlusion queries")
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19400>
(cherry picked from commit 5c5e4238ff8f9dfb92b13071582af13c985483ef)
It's undefined behavior in C to read a union member if another member
has been written to more recently. Let's be more careful here!
Fixes: a9d2b86c2c ("zink: store the spirv_shader to the zink_shader struct for generated tcs")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19457>
(cherry picked from commit 090a111c5dcd2c6764e7b990a55f3bddca771499)
6698753cdb switched our GS output stores to use MUBUF.
The stride doesn't matter for the ESGS descriptor (because idxen=false and
the index stride is 64), but this fixes it anyway.
This also changes ACO to use MUBUF store too, since MTBUF doesn't seem to
work correctly with an invalid data format in the descriptor.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Fixes: 6698753cdb ("ac/llvm: don't use tbuffer_store as a fallback for swizzled stores")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18885>
(cherry picked from commit a71d068fd07f5d34561b28f2f57267031077033a)
Recently, a regression was reported where videos in Firefox had shifted/
glitched colors on certain Kepler hardware. This was bisected to
bf02bffe15, however, the issue already
existed but didn't hit users until TGSI was switched to NIR as default.
The issue was traced to a YUV-to-RGB fragment shader used by Firefox,
which uses three samplers for the Y/U/V components. The Y component was
handled correctly, but the U/V components were bogus, causing the issue.
After analysis, it appears the TXF/TXQ ops. should only handle the texture
(r) but not the sampler (s), see 63b850403c
and 346ce0b988.
Similarly, handleTXQ/handleTXF on nv50_ir_from_tgsi always sets s=0.
Only Kepler was affected because other hardware ignores s at codegen.
Always set s=0 on NIR for TXF/TXQ, to keep TGSI behavior and fix the
regression.
Thanks: Karol Herbst and M Henning for help diagnosing the issue.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7416
Cc: mesa-stable
Suggested-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: M Henning <drawoc@darkrefraction.com>
Signed-off-by: Joan Bruguera <joanbrugueram@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19453>
(cherry picked from commit 6014a642ae24e37c287adbf41d615efa18d0da3d)
It improves performance of vk_meshlet_cadscene on A770.
Fixes: f083df8710 ("anv: update task/mesh distribution with the recommended values")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19412>
(cherry picked from commit dcaaeb56ef2951282225cc598fcd8781ed09f796)
Documentation is worded in a confusing way, which may be understood that
we don't have to set this field to get good results.
MESH part of this commit improves performance of vk_meshlet_cadscene
by a factor of 2 on A380.
Fixes: ef04caea9b ("anv: Implement Mesh Shading pipeline")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19412>
(cherry picked from commit d1d2dee9708b5a3624696460d27969bc03940395)
From empirical tests (on a660) R8G8 with UBWC enabled requires 256b
alignment, otherwise there would be a GPU fault during blits.
Set alignment to 4096 for all UBWC images since that's what blob does
and this area is heavily undertested.
Fixes GPU fault in Borderlands 3 running through DXVK.
cc: mesa-stable
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19298>
(cherry picked from commit 5eaca461a774f6f8466402b5facfc426cee9f1fd)
display_ver doesn't seem to be used anywhere, but if that were to
change, we'd want this to be consistent.
Fixes: c746bf4c5c ("intel/dev: Add display_ver and set adl-p to 13")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19354>
(cherry picked from commit 3ef88cd0a2de26e56def43db969f98c80235f065)
In 7f6ecb8667 we added reference counting for descriptor set layouts,
however, we didn't realize that pools created without the flag
VK_DESCRIPTOR_POOL_CREATE_FREE_DESCRIPTOR_SET_BIT don't free individual
descriptors and can only be reset or destroyed. Since we only drop
references when individual descriptor sets were destroyed, we would
leak set layouts referenced from descriptor sets allocated from these
pools.
Fix that by keeping a list of all allocated descriptor sets (no matter
whether VK_DESCRIPTOR_POOL_CREATE_FREE_DESCRIPTOR_SET_BIT is present or
not) and then traversing the list dropping the references on pool resets
and destroys.
Fixes: 7f6ecb8667 ('v3dv: add reference counting for descriptor set layouts')
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19337>
(cherry picked from commit 07c7d846e5fa6867ce20dd959b4609fd1a0f1646)
