Use a lightweight container for ping, ssh, curl and bash support.
Also use an image located at fd.o infrastructure, since we are having
some issues with Collabora's gitlab one lately.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23534>
- To keep things organized, create a base hidden jobs for alpine images,
as we have 2 now
- This image will have an SSH client ran by LAVA dispatchers
(x86_64-only) who will serve as a bypass channel of output and dmesg
and an alternative for UART.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23534>
Our LAVA farm is currently experiencing issues with running and pulling
docker. LAVA has been detecting (with a low rate) timeouts during these
commands, causing some jobs to fail with infrastructure errors.
Increasing the failure_retry will make the job retry run the container
when LAVA detects the failure without losing its place in the job queue.
We are currently investigating why docker times out. But, when LAVA
fails to detect it, we cancel the job on our side and resubmit it to the
job queue. For more information, please refer to following dashboard:
https://ci-stats-grafana.freedesktop.org/goto/VjZvaA_4z?orgId=1
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23534>
The pipe cap isn't really accurate since shaders created by lavapipe take
a different codepath compared to GL. The format information is part of
the descriptor.
This allows vkd3d-proton to advertise typed UAV loads. (Whatever that
means)
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24014>
Some drivers might return 0 indicating they haven't written any data. But
treating it as 0 for all current `COMPUTE_CAP`s is fine, so no need to
panic at runtime here.
Signed-off-by: Karol Herbst <git@karolherbst.de>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Nora Allen <blackcatgames@protonmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22893>
This will be required for `cl_intel_required_subgroup_size`, but it
already helps implementing OpenCL subgroups as this allows us to check
with every subgroup size when implementing
`CL_KERNEL_LOCAL_SIZE_FOR_SUB_GROUP_COUNT`.
Signed-off-by: Karol Herbst <git@karolherbst.de>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22893>
Same as DIV_ROUND_UP
Signed-off-by: Karol Herbst <git@karolherbst.de>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Nora Allen <blackcatgames@protonmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22893>
This will be required by drivers supporting multiple subgroup sizes with
a given CSO to properly implement OpenCL subgroups.
Signed-off-by: Karol Herbst <git@karolherbst.de>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22893>
OpenCL 3.0 core requires __opencl_c_subgroups to be set, the OpenCL
cl_khr_subgroups extenions can only be enabled if and only if the driver
guarentees independent forward progress between subgroups.
See CL_DEVICE_SUB_GROUP_INDEPENDENT_FORWARD_PROGRESS for more information.
Signed-off-by: Karol Herbst <git@karolherbst.de>
Reviewed-by: Nora Allen <blackcatgames@protonmail.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22893>
This only applies to Intel's ray tracing. With RADV also having
ray tracing support that is always compiled in, seeing
"Ray Tracing: NO" is a bit misleading.
Reviewed-by: Joshua Ashton <joshua@froggi.es>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24008>
The BLT blit currently assumes that all blits with src samples > 1
are downsampling blits. This isn't correct, as we can also blit
between two multisampled resources with src and dst samples > 1.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23595>
When blitting between two multisampled resources, the blit region needs
to be scaled by the number of samples. Currently this is only done
correctly for downsampling blits where src samples > dst samples. Fix
it to also work as expected when src samples == dst samples.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23595>
Width and height of the resource level are stored in pixels, while
the padded dimensions are stored in samples. Move the members to
make them line up with the comments.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23595>
If an array is accessed indirectly, add a buffer live range of
one cycle before (for write) or after (for read), instead of pinning
the array from the start.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24036>
If we try to re-use the AR register after a new CF was started
we will get into trouble, because it is no longer loaded, so
clear the AR register handle when we hit a non-ALU instruction
while scanning the shader to split AR loads. With that
dependencies will be set accodingly.
Fixes: d21054b4bc
r600/sfn: Add pass to split address and index register loads
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24036>
On Pre-Evergreen hardware we have a flag
"Force Clamp X,Y policy to wrap for CubeMaps"
but it doesn't seem to affect how border clamping is done. With
bf3027 this is set to PIPE_TEX_WRAP_CLAMP_TO_EDGE for cube maps,
and results in the regression reported in #9028.
Forcing repeat mode fixes the issue.
Fixes: bf3027c391
mesa/st: Normalize wrap modes for seamless cubes
Related: https://gitlab.freedesktop.org/mesa/mesa/-/issues/9028
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23848>
We're interested in a Vulkan-only stack in Chrome OS, where Android's GLES
would be provided by ANGLE-over-Venus-over-RADV. Let's get some testing
covering ANGLE-on-RADV first.
This is structured as a single partial job pre-merge to catch most
regressions, and 2 longer manual jobs to do full coverage for when you
need to update the xfails list.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20163>
We're interested in a Vulkan-only stack in Chrome OS, where Android's GLES
would be provided by ANGLE-over-Venus-over-ANV. Let's get some testing
covering ANGLE-on-ANV first.
This is structured as a single partial job pre-merge to catch most
regressions, and a longer manual job to do full coverage for when you need
to update the xfails list.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20163>
There's no functional changes:
1. remove unused function arg and use snake case
2. do early return for direct recording (avoid dup feedback checks)
3. use vk_alloc instead of vk_zalloc if applicable
4. move local struct closer to usage, and use assignment
5. convert secondary cmd in_render_pass condition check to assert
6. avoid redundant list_del upon freeing up
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24009>
vkd3d-proton always use concurrent sharing when there exists multiple
queue families, and all queue families are used. This change adds the
exact simple case to the existing cache.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23916>