The function name is updated to r600_as_resource().
This is done with the command below with some manual adjustments:
find . -type f -name "*.c" -exec grep -lE " = [(]struct[[:space:]]+r600_resource[[:space:]]*\*[)]" {} + |\
xargs sed -r -i "s/[(]struct[[:space:]]+r600_resource[[:space:]]*\*[)]([^;]*);/r600_as_resource(\1);/"
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35967>
This is done with the command below with some manual adjustments:
find . -type f -name "*.c" -exec grep -lE " = [(]struct[[:space:]]+r600_texture[[:space:]]*\*[)]" {} + |\
xargs sed -r -i "s/[(]struct[[:space:]]+r600_texture[[:space:]]*\*[)]([^;]*);/r600_as_texture(\1);/"
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35967>
These are not necessary and can be expensive. I think they were added
because of a misunderstanding of the informative descriptions in the
Vulkan memory model, or because the memory model requires make
visible/available barriers to have these semantics.
Because we use these to implement MakePointerVisible/MakePointerAvailable,
we can skip that requirement in NIR.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36080>
From Vulkan 1.4.321 spec:
The implicit availability operation is program-ordered between the barrier
or atomic and all other operations program-ordered before the barrier or
atomic.
...
The implicit visibility operation is program-ordered between the barrier
or atomic and all other operations program-ordered after the barrier or
atomic.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36080>
We can use the init-stage1 script from the Mesa build artifacts instead of
keeping a copy in the lava-trigger container and inlining it into the
LAVA job definition.
v2 (Guilherme)
* Source the `init-stage1.sh` file instead of executing it
* Avoid hardcoding the run_steps asserts, check only the core parts
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Co-authored-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36549>
This change ensures a deterministic state compatible with
the expected ARB_shader_image_load_store behavior when an
incomplete shader image is detected.
Note: "spec/arb_shader_image_load_store/invalid/.*/address bounds test/.*"
are not addressed by this change.
This change was tested on cypress, palm, barts and cayman and
fixes the remaining issues concerning the following tests:
khr-gl4[2-6]/shader_image_load_store/incomplete_textures: fail pass
spec/arb_shader_image_load_store/invalid/.*/format mismatch test: fail pass
spec/arb_shader_image_load_store/invalid/.*/incompatible format test: fail pass
spec/arb_shader_image_load_store/invalid/.*/incomplete image test: fail pass
spec/arb_shader_image_load_store/invalid/.*/index bounds test: fail pass
spec/arb_shader_image_load_store/invalid/.*/invalid format test: fail pass
spec/arb_shader_image_load_store/invalid/.*/layer bounds test: fail pass
spec/arb_shader_image_load_store/invalid/.*/level bounds test: fail pass
spec/arb_shader_image_load_store/invalid/.*/target mismatch test: fail pass
spec/arb_shader_image_load_store/invalid/.*/unbound image test: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35685>
This functionality is working properly on rv770, but some
issues remain for the newer r600 gpus. These issues are not the
same for cypress and for palm and beyond.
As far as palm and beyond is concerned this change is consistent
with the radeonsi commit: 50c95d0c54 "radeonsi: reject some
3-component formats as buffer textures". This is explained
in a comment of this other commit.
This change assumes that all the real evergreen gpus (before
palm) behave like cypress.
This change was tested on palm, barts and cayman. Here are the tests fixed:
deqp-gles3/functional/texture/specification/teximage2d_pbo/rgb16f_cube: fail pass
deqp-gles3/functional/texture/specification/teximage2d_pbo/rgb16i_cube: fail pass
deqp-gles3/functional/texture/specification/teximage2d_pbo/rgb16ui_cube: fail pass
deqp-gles31/functional/texture/specification/teximage3d_pbo/rgb16f_cube_array: fail pass
deqp-gles31/functional/texture/specification/teximage3d_pbo/rgb16i_cube_array: fail pass
deqp-gles31/functional/texture/specification/teximage3d_pbo/rgb16ui_cube_array: fail pass
This change was also tested on cypress. Here are the tests fixed:
deqp-gles3/functional/texture/specification/teximage[23]d_pbo/rgb565_2d: fail pass
deqp-gles3/functional/texture/specification/teximage[23]d_pbo/rgb565_cube: fail pass
deqp-gles3/functional/texture/specification/teximage[23]d_pbo/rgb5_a1_2d: fail pass
deqp-gles3/functional/texture/specification/teximage[23]d_pbo/rgb5_a1_cube: fail pass
deqp-gles3/functional/texture/specification/teximage[23]d_pbo/rgba4_2d: fail pass
deqp-gles3/functional/texture/specification/teximage[23]d_pbo/rgba4_cube: fail pass
deqp-gles3/functional/texture/specification/texsubimage[23]d_pbo/rgb565_2d: fail pass
deqp-gles3/functional/texture/specification/texsubimage[23]d_pbo/rgb565_cube: fail pass
deqp-gles3/functional/texture/specification/texsubimage[23]d_pbo/rgb5_a1_2d: fail pass
deqp-gles3/functional/texture/specification/texsubimage[23]d_pbo/rgb5_a1_cube: fail pass
deqp-gles3/functional/texture/specification/texsubimage[23]d_pbo/rgba4_2d: fail pass
deqp-gles3/functional/texture/specification/texsubimage[23]d_pbo/rgba4_cube: fail pass
deqp-gles31/functional/texture/specification/teximage3d_pbo/rgb565_cube_array: fail pass
deqp-gles31/functional/texture/specification/teximage3d_pbo/rgb5_a1_cube_array: fail pass
deqp-gles31/functional/texture/specification/teximage3d_pbo/rgba4_cube_array: fail pass
deqp-gles31/functional/texture/specification/texsubimage3d_pbo/rgb565_cube_array: fail pass
deqp-gles31/functional/texture/specification/texsubimage3d_pbo/rgb5_a1_cube_array: fail pass
deqp-gles31/functional/texture/specification/texsubimage3d_pbo/rgba4_cube_array: fail pass
Cc: mesa-stable
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35430>
`Xvfb` segfaults 100% of the time in the nightly `llvmpipe-full` job;
not sure why the merge job `llvmpipe` wasn't affected, but also we have
no reason to use Xvfb instead of Xwayland.
Note that in 3 out of 50 runs, Xwayland also crashed with the same
message; that's a much better percentage than the current state though 😇
(EE) Backtrace:
(EE) 0: /usr/local/bin/Xwayland (0x55f43181a000+0x1ece97) [0x55f431a06e97]
(EE) 1: /usr/local/bin/Xwayland (0x55f43181a000+0x1f0ad9) [0x55f431a0aad9]
(EE) 2: /lib/x86_64-linux-gnu/libc.so.6 (0x7f1270c6a000+0x3c050) [0x7f1270ca6050]
(EE) 3: /usr/local/bin/Xwayland (0x55f43181a000+0x174f62) [0x55f43198ef62]
(EE) 4: /usr/local/bin/Xwayland (0x55f43181a000+0x14dcfa) [0x55f431967cfa]
(EE) 5: /usr/local/bin/Xwayland (0x55f43181a000+0x14ee17) [0x55f431968e17]
(EE) 6: /usr/local/bin/Xwayland (0x55f43181a000+0x1529ae) [0x55f43196c9ae]
(EE) 7: /usr/local/bin/Xwayland (0x55f43181a000+0x147192) [0x55f431961192]
(EE) 8: /usr/local/bin/Xwayland (0x55f43181a000+0x14a025) [0x55f431964025]
(EE) 9: /usr/local/bin/Xwayland (0x55f43181a000+0x11640e) [0x55f43193040e]
(EE) 10: /usr/local/bin/Xwayland (0x55f43181a000+0x11bc5e) [0x55f431935c5e]
(EE) 11: /usr/local/bin/Xwayland (0x55f43181a000+0x11fc04) [0x55f431939c04]
(EE) 12: /lib/x86_64-linux-gnu/libc.so.6 (0x7f1270c6a000+0x2724a) [0x7f1270c9124a]
(EE) 13: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) [0x7f1270c91305]
(EE) 14: /usr/local/bin/Xwayland (0x55f43181a000+0xa2341) [0x55f4318bc341]
(EE)
(EE) Segmentation fault at address 0x4
(EE)
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)
[00:39:05.907] /usr/local/bin/Xwayland died on signal 6
[00:39:05.908] xserver exited, will restart on demand
That "will restart on demand" is clearly not working btw, not sure if
that' Xwayland or weston doing something wrong, but I doubt it's
anything on our side.
A debug build of Xwayland would give us more info, but we don't want to
run CI on a debug build, so that will be something to do in a fork build
for whoever wants to investigate that:
```patch
diff --git ./.gitlab-ci/container/build-xwayland.sh ./.gitlab-ci/container/build-xwayland.sh
index 04072794727147baebf8..1b94b3c56d6948b1cece 100644
--- ./.gitlab-ci/container/build-xwayland.sh
+++ ./.gitlab-ci/container/build-xwayland.sh
@@ -23,7 +23,7 @@
git clone https://gitlab.freedesktop.org/xorg/xserver
cd xserver
git checkout "$XWAYLAND_VERSION"
-meson setup _build ${EXTRA_MESON_ARGS:-}
+meson setup _build ${EXTRA_MESON_ARGS:-} --buildtype debug
meson install -C _build
cd ..
rm -rf xserver
```
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36485>
Specifically, set WAYLAND_DISPLAY only once and reuse the var, don't
export it to weston itself (even though it's ignored because we
explicitly select the headless backend instead of auto), use long option
names for added clarity, and replace deprecated `--use-gl` with
`--renderer=gl`.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36485>
On JM hardware, we need to allocate a buffer depending on vertex count.
As a result, for indirect and indexed draw we allocate a large buffer with
alloc on fault set.
The size of that buffer is calculated assuming a max of 2 millions vertices
and 18 attributes per vertex (16 user attributes, 2 specials)
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Olivia Lee <olivia.lee@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35724>
this catches the case where an app resolves both color and depth buffers
previously the inlining would only catch the first color buffer, then the depth
resolve which followed would cause the whole of rp tracking to desync and
explode, as seen in Transport Fever 2
Fixes: 8933b3ed39 ("tc: add resolve resource to rp info")
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36521>
Patrick Lerda