mirrors/mesa
0
0
Fork 0
mirror of https://gitlab.freedesktop.org/mesa/mesa.git synced 2024-11-23 18:24:13 +08:00
Code Issues Packages Projects Releases Wiki Activity
7d24cef200
mesa/.gitlab-ci.yml

591 lines
14 KiB
YAML
Raw Normal View History

gitlab-ci: add ubuntu container Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-20 19:21:45 +08:00
# This is the tag of the docker image used for the build jobs. If the
gitlab-ci: rename stages to something simpler Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2019-09-12 01:51:46 +08:00
# image doesn't exist yet, the containers stage generates it.
gitlab-ci: add ubuntu container Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-20 19:21:45 +08:00
#
# In order to generate a new image, one should generally change the tag.
# While removing the image from the registry would also work, that's not
# recommended except for ephemeral images during development: Replacing
# an image after a significant amount of time might pull in newer
# versions of gcc/clang or other packages, which might break the build
# with older commits using the same tag.
#
# After merging a change resulting in generating a new image to the
# main repository, it's recommended to remove the image from the source
# repository's container registry, so that the image from the main
# repository's registry will be used there as well.
variables:
CI: use wayland ci-templates repo to create the base image There shouldn't be a difference for users, but this way we do manage all of our containers from freedesktop.org note: compared to the provious Dockerfile, we need to manually add gcc, g++ and python*-wheel Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-04-02 15:24:00 +08:00
UPSTREAM_REPO: mesa/mesa
ci: Use several debian buster packages instead of hand-building. This helps cut down our container build time. I've left a few that we're likely to rev more frequently or I was less confident in dropping. v2: Rebase on the build/test container split, now bumps the build container tag in this commit. Acked-by: Eric Engestrom <eric.engestrom@intel.com> (v1) Acked-by: Daniel Stone <daniels@collabora.com> (v1)
2019-11-05 03:05:25 +08:00
DEBIAN_TAG: "amd64-2019-11-13-2"
gitlab-ci: update Piglit commit, update skips Signed-off-by: Tapani Pälli <tapani.palli@intel.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2019-11-15 13:12:24 +08:00
DEBIAN_TEST_TAG: "amd64-test-2019-11-15"
gitlab-ci: build a specific libdrm version for ARM64 RADV requires libdrm-2.4.100 but the distrib package is too old. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-11-12 21:56:35 +08:00
DEBIAN_ARM64_TAG: "arm64v8-2019-11-13"
ci: Use cts_runner for our dEQP runs. This runner is a little project by Bas, written in C++, that spawns threads that then loop grabbing chunks of the (randomly shuffled but consistently so) test list and hand it to a dEQP instance. As the remaining list gets shorter, so do the chunks, so hopefully the threads all complete effectively at once. It also handles restarting after crashes automatically. I've extended the runner a bit to do what I was doing in the bash scripts before, like the skip list and expected failures handling. This project should also be a good baseline for extending to handle retesting of intermittent failures. By switching to it, we can have the swrast tests just take up one job slot on the shared runners and keep their allotment of CPUs busy, instead of taking up job slots with single-threaded dEQP jobs. It will also let us (eventually, once I reprovision) switch the freedreno runners over to threading within the job instead of running concurrent jobs, so that memory scribbles in one pipeline don't affect unrelated pipelines, and I can experiment with their parallelism (particularly on a306 where we are frequently backed up) without trashing other people's jobs. What we lose in this process is per-test output in the log (not a big loss, I think, since we summarize fails at the end and reducing log length keeps chrome from choking on our logs so badly). We also drop the renderer sanity checking, since it's not saving qpa files for us to go poke through. Given that all the drivers involved have fail lists, if we got the wrong renderer somehow, we'd get a job failure anyway. v2: Rebase on droppong of the autoscale cluster and the arm64 build/test split. Use a script to deduplicate the cts-runner build. v3: Rebase on the amd64 build/test container split. Acked-by: Daniel Stone <daniels@collabora.com> (v1) Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> (v2)
2019-11-05 02:54:41 +08:00
DEBIAN_ARM64_TEST_TAG: "arm64v8-test-2019-11-12-2"
gitlab-ci: Create separate docker images for Debian stretch & buster Pros: * Less fragile due to not mixing packages from stretch and buster * No longer need to use third-party LLVM packages * The buster image now uses GCC 8 for C++ as well (previously 6 for C++, 8 for C), allowing to drop some hacks Con: * The stretch image now only uses GCC 6 for C as well as C++ * Need separate jobs for testing old LLVM versions Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-09-06 23:04:47 +08:00
STRETCH_TAG: "2019-09-18"
DEBIAN_VERSION: buster-slim
STRETCH_VERSION: stretch-slim
gitlab-ci: Use Debian stretch instead of Ubuntu bionic The APT archive used by the Ubuntu docker image can be slow, even timing out sometimes, causing spurious failures of the containers-build job. The Debian docker image uses deb.debian.org, which is backed by a content distribution network. One downside is that stretch only has GCC 6, whereas bionic had 7. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-04-02 22:56:54 +08:00
DEBIAN_IMAGE: "$CI_REGISTRY_IMAGE/debian/$DEBIAN_VERSION:$DEBIAN_TAG"
gitlab-ci: Use separate docker images for x86 build/test jobs Same as was done for the ARM images before. This should make it less painful to update to newer dEQP / piglit as well as to make changes to the build/test environment. Reviewed-by: Eric Anholt <eric@anholt.net>
2019-11-06 01:52:24 +08:00
DEBIAN_TEST_IMAGE: "$CI_REGISTRY_IMAGE/debian/$DEBIAN_VERSION:$DEBIAN_TEST_TAG"
gitlab-ci: Create separate docker images for Debian stretch & buster Pros: * Less fragile due to not mixing packages from stretch and buster * No longer need to use third-party LLVM packages * The buster image now uses GCC 8 for C++ as well (previously 6 for C++, 8 for C), allowing to drop some hacks Con: * The stretch image now only uses GCC 6 for C as well as C++ * Need separate jobs for testing old LLVM versions Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-09-06 23:04:47 +08:00
DEBIAN_ARM64_IMAGE: "$CI_REGISTRY_IMAGE/debian/$DEBIAN_VERSION:$DEBIAN_ARM64_TAG"
gitlab-ci: Use separate arm64 build/test docker images The image used for test jobs is only about 1/6 as big as before, which may help avoid some issues with some of the test boards. Inspired by https://gitlab.freedesktop.org/mesa/mesa/issues/2046 . v2: * Leave LIBDRM_VERSION at 2.4.99 (Daniel Stone) * Delete more build artifacts from dEQP tree (Daniel Stone) v3: * Set LD_LIBRARY_PATH for ldd Acked-by: Daniel Stone <daniels@collabora.com> # v2 Reviewed-by: Eric Anholt <eric@anholt.net> # Except for the ldd line
2019-11-04 16:54:09 +08:00
DEBIAN_ARM64_TEST_IMAGE: "$CI_REGISTRY_IMAGE/debian/$DEBIAN_VERSION:$DEBIAN_ARM64_TEST_TAG"
gitlab-ci: Create separate docker images for Debian stretch & buster Pros: * Less fragile due to not mixing packages from stretch and buster * No longer need to use third-party LLVM packages * The buster image now uses GCC 8 for C++ as well (previously 6 for C++, 8 for C), allowing to drop some hacks Con: * The stretch image now only uses GCC 6 for C as well as C++ * Need separate jobs for testing old LLVM versions Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-09-06 23:04:47 +08:00
STRETCH_IMAGE: "$CI_REGISTRY_IMAGE/debian/$STRETCH_VERSION:$STRETCH_TAG"
CI: use wayland ci-templates repo to create the base image There shouldn't be a difference for users, but this way we do manage all of our containers from freedesktop.org note: compared to the provious Dockerfile, we need to manually add gcc, g++ and python*-wheel Signed-off-by: Benjamin Tissoires <benjamin.tissoires@gmail.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-04-02 15:24:00 +08:00
include:
- project: 'wayland/ci-templates'
gitlab-ci: Reference full ci-templates commit hash 8 digits might become ambiguous at some point. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-09-06 23:01:50 +08:00
ref: 1f7f57c64ff4ebbf7292e3b7a13600518b8cb24c
gitlab-ci: Use Debian stretch instead of Ubuntu bionic The APT archive used by the Ubuntu docker image can be slow, even timing out sometimes, causing spurious failures of the containers-build job. The Debian docker image uses deb.debian.org, which is backed by a content distribution network. One downside is that stretch only has GCC 6, whereas bionic had 7. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-04-02 22:56:54 +08:00
file: '/templates/debian.yml'
gitlab-ci: add ubuntu container Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-20 19:21:45 +08:00
gitlab-ci: Run dEQP on devices with Panfrost Include Panfrost's gitlab.ci.yml file from Mesa's main .gitlab-ci.yml so we test on devices with Panfrost. This uses LAVA to schedule jobs in the devices and will be the base for testing Etnaviv, Lima, etc. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-18 22:03:36 +08:00
include:
gitlab-ci: Add a job for meson on windows This adds a new CI job that runs on windows with MSVC. It currently builds softpipe and osmesa, and runs the related unit tests. It does rely on meson's wraps for zlib, but I've set up caching of the wrap dependencies so hopefully that wont be a problem. I really wanted to user powershell for this, but there just isn't an easy way to do that, it's much easier to use batch scripts, so thats what I used. The leading `/` for .gitlab-ci/lava... must be removed because windows doesn't understand it, and when it reads the file the job ends in error. Reviewed-by: Eric Engestrom <eric@engestrom.ch>
2019-10-24 05:36:19 +08:00
- local: '.gitlab-ci/lava-gitlab-ci.yml'
gitlab-ci: Run dEQP on devices with Panfrost Include Panfrost's gitlab.ci.yml file from Mesa's main .gitlab-ci.yml so we test on devices with Panfrost. This uses LAVA to schedule jobs in the devices and will be the base for testing Etnaviv, Lima, etc. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-18 22:03:36 +08:00
gitlab-ci: add ubuntu container Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-20 19:21:45 +08:00
stages:
gitlab-ci: set a common job parent for container stage While at it, rename to singular "container" for consistency. Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2019-10-15 06:04:14 +08:00
- container
gitlab-ci: rename stages to something simpler Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2019-09-12 01:51:46 +08:00
- build
gitlab-ci: Run the GLES2 CTS on llvmpipe. This is the start of doing CTS tests on merges to Mesa master. We use the surfaceless platform so that we don't need to bother bringing up weston or X11. The surface size is kept low to reduce runtime, but this comes at the cost of many rendering tests skipping due to too-small render targets (as we see the impact of Mesa on the shared runner pool, we can reevaluate this and what set of CTS tests we want to run). We split the job up across 4 runners (each at 4 llvmpipe threads), so that the job can load-balance across our shared runners and finish sooner (since dEQP is very single-thread-performance bound). Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-06-29 07:35:32 +08:00
- test
gitlab-ci: add ubuntu container Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-20 19:21:45 +08:00
gitlab-ci: always run the containers build If the first time a fork was created, the job creating the containers was manually cancelled, this would have left the fork unable to use the CI (until the next automatic regeneration of the container). Avoid this by always running the container-generation job, even though 99% of the time it will spin up, see that the container exists and shut down. Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
2019-02-22 23:52:08 +08:00
# When to automatically run the CI
gitlab-ci: Use multiple inheritance instead of YAML references Support for multiple inheritance was added to GitLab recently. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-06 23:35:52 +08:00
.ci-run-policy:
gitlab-ci: always run the containers build If the first time a fork was created, the job creating the containers was manually cancelled, this would have left the fork unable to use the CI (until the next automatic regeneration of the container). Avoid this by always running the container-generation job, even though 99% of the time it will spin up, see that the container exists and shut down. Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
2019-02-22 23:52:08 +08:00
only:
gitlab-ci: Only run the pipeline if any files affecting it have changed E.g. documentation-only changes cannot affect the outcome of the pipeline, so don't waste resources on running it. The thing we need to be careful about here is that the container stage jobs must always run if any later stage jobs using the corresponding docker images run. We're currently using the same .ci-run-policy template for all jobs, so this is trivially true. v2: * Add bin/ and common.py (Eric Engestrom) Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> # v1 Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-10-26 00:59:56 +08:00
refs:
- branches@mesa/mesa
- merge_requests
- /^ci([-/].*)?$/
changes:
- VERSION
- bin/**/*
# GitLab CI
- .gitlab-ci.yml
- .gitlab-ci/**/*
# Meson
- meson*
- build-support/**/*
- subprojects/**/*
# SCons
- SConstruct
- scons/**/*
- common.py
# Source code
- include/**/*
- src/**/*
gitlab-ci: Automatically retry jobs after runner system failure Up to twice, for a total of 3 attempts maximum. This will hopefully avoid spurious CI pipeline failures due to intermittent GitLab/docker infrastructure issues. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-03-27 01:39:41 +08:00
retry:
max: 2
when:
- runner_system_failure
gitlab-ci: auto-cancel CI runs when a newer commit is pushed to the same branch Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2019-11-13 07:42:21 +08:00
# Cancel CI run if a newer commit is pushed to the same branch
interruptible: true
gitlab-ci: always run the containers build If the first time a fork was created, the job creating the containers was manually cancelled, this would have left the fork unable to use the CI (until the next automatic regeneration of the container). Avoid this by always running the container-generation job, even though 99% of the time it will spin up, see that the container exists and shut down. Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
2019-02-22 23:52:08 +08:00
gitlab-ci: Use multiple inheritance instead of YAML references Support for multiple inheritance was added to GitLab recently. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-06 23:35:52 +08:00
.ci-deqp-artifacts:
gitlab-ci: Run the GLES2 CTS on llvmpipe. This is the start of doing CTS tests on merges to Mesa master. We use the surfaceless platform so that we don't need to bother bringing up weston or X11. The surface size is kept low to reduce runtime, but this comes at the cost of many rendering tests skipping due to too-small render targets (as we see the impact of Mesa on the shared runner pool, we can reevaluate this and what set of CTS tests we want to run). We split the job up across 4 runners (each at 4 llvmpipe threads), so that the job can load-balance across our shared runners and finish sooner (since dEQP is very single-thread-performance bound). Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-06-29 07:35:32 +08:00
artifacts:
when: always
untracked: false
paths:
# Watch out! Artifacts are relative to the build dir.
# https://gitlab.com/gitlab-org/gitlab-ce/commit/8788fb925706cad594adf6917a6c5f6587dd1521
- artifacts
gitlab-ci: always run the containers build If the first time a fork was created, the job creating the containers was manually cancelled, this would have left the fork unable to use the CI (until the next automatic regeneration of the container). Avoid this by always running the container-generation job, even though 99% of the time it will spin up, see that the container exists and shut down. Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
2019-02-22 23:52:08 +08:00
gitlab-ci: Create separate docker images for Debian stretch & buster Pros: * Less fragile due to not mixing packages from stretch and buster * No longer need to use third-party LLVM packages * The buster image now uses GCC 8 for C++ as well (previously 6 for C++, 8 for C), allowing to drop some hacks Con: * The stretch image now only uses GCC 6 for C as well as C++ * Need separate jobs for testing old LLVM versions Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-09-06 23:04:47 +08:00
# Build the normal CI native and cross-build docker images.
gitlab-ci: set a common job parent for container stage While at it, rename to singular "container" for consistency. Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2019-10-15 06:04:14 +08:00
.container:
stage: container
extends:
- .ci-run-policy
variables:
# no need to pull the whole repo to build the container image
GIT_STRATEGY: none
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
debian-10:amd64:
gitlab-ci: Use multiple inheritance instead of YAML references Support for multiple inheritance was added to GitLab recently. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-06 23:35:52 +08:00
extends:
- .debian@container-ifnot-exists
gitlab-ci: set a common job parent for container stage While at it, rename to singular "container" for consistency. Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2019-10-15 06:04:14 +08:00
- .container
gitlab-ci: add ubuntu container Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-20 19:21:45 +08:00
variables:
gitlab-ci: Use Debian stretch instead of Ubuntu bionic The APT archive used by the Ubuntu docker image can be slow, even timing out sometimes, causing spurious failures of the containers-build job. The Debian docker image uses deb.debian.org, which is backed by a content distribution network. One downside is that stretch only has GCC 6, whereas bionic had 7. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-04-02 22:56:54 +08:00
DEBIAN_EXEC: 'bash .gitlab-ci/debian-install.sh'
gitlab-ci: add a meson vulkan build Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-20 19:26:53 +08:00
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
.use-debian-10:amd64:
gitlab-ci: Add .use-debian-10 template It simplifies the definitions of jobs using the Debian 10 image. The needs: was previously missing from the llvmpipe/softpipe test jobs, so they could spuriously run if the debian-10 job failed or was cancelled. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-10-10 21:27:17 +08:00
image: $DEBIAN_IMAGE
needs:
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
- debian-10:amd64
gitlab-ci: Add .use-debian-10 template It simplifies the definitions of jobs using the Debian 10 image. The needs: was previously missing from the llvmpipe/softpipe test jobs, so they could spuriously run if the debian-10 job failed or was cancelled. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-10-10 21:27:17 +08:00
gitlab-ci: Use separate docker images for x86 build/test jobs Same as was done for the ARM images before. This should make it less painful to update to newer dEQP / piglit as well as to make changes to the build/test environment. Reviewed-by: Eric Anholt <eric@anholt.net>
2019-11-06 01:52:24 +08:00
debian-10-test:amd64:
extends: debian-10:amd64
variables:
DEBIAN_TAG: "$DEBIAN_TEST_TAG"
DEBIAN_EXEC: 'bash .gitlab-ci/debian-test-install.sh'
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
debian-9:amd64:
extends: debian-10:amd64
gitlab-ci: Create separate docker images for Debian stretch & buster Pros: * Less fragile due to not mixing packages from stretch and buster * No longer need to use third-party LLVM packages * The buster image now uses GCC 8 for C++ as well (previously 6 for C++, 8 for C), allowing to drop some hacks Con: * The stretch image now only uses GCC 6 for C as well as C++ * Need separate jobs for testing old LLVM versions Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-09-06 23:04:47 +08:00
variables:
DEBIAN_TAG: $STRETCH_TAG
DEBIAN_VERSION: $STRETCH_VERSION
DEBIAN_IMAGE: $STRETCH_IMAGE
DEBIAN_EXEC: 'bash .gitlab-ci/debian-stretch-install.sh'
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
.use-debian-9:amd64:
gitlab-ci: Declare needs: for stretch docker image This allows the *-old-llvm jobs to run before the buster docker images are ready. v2: * Use - list syntax instead of [] (Eric Engestrom) Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-18 22:17:01 +08:00
image: $STRETCH_IMAGE
needs:
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
- debian-9:amd64
gitlab-ci: Declare needs: for stretch docker image This allows the *-old-llvm jobs to run before the buster docker images are ready. v2: * Use - list syntax instead of [] (Eric Engestrom) Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-18 22:17:01 +08:00
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
debian-10:arm64:
gitlab-ci: Use multiple inheritance instead of YAML references Support for multiple inheritance was added to GitLab recently. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-06 23:35:52 +08:00
extends:
- .debian@container-ifnot-exists@arm64v8
gitlab-ci: set a common job parent for container stage While at it, rename to singular "container" for consistency. Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2019-10-15 06:04:14 +08:00
- .container
freedreno: Introduce gitlab-based CI. Since freedreno's kernel and GPU reset seem to be totally solid, we don't need to have the complexity of the LAVA setup that panfrost has. Instead, we can register some boards as shared gitlab runners and have the jobs run out of a docker container just like we do for llvmpipe. Just make sure that the DRI device node is passed through to the containers in the gitlab config ('devices = ["/dev/dri"]' under runners.docker). If a runner fails (networking dies, kernel panic, etc.) it'll take out one build but the rest can keep going since gitlab-runner is what pulls jobs. Since the runner pulls jobs, it also means that they can live behind firewalls instead of needing some public address to be accessed by gitlab.fd.o. For now, enable it just on db410c (A307) and cheza (A630) as those are the hardware that I have plenty of. A307 is only testing GLES2 since running all of GLES3 takes too long for the number of boards I've brought up. Acked-by: Rob Clark <robdclark@chromium.org> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2019-06-29 07:35:32 +08:00
variables:
DEBIAN_TAG: "$DEBIAN_ARM64_TAG"
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
DEBIAN_EXEC: 'bash .gitlab-ci/debian-arm64-install.sh'
gitlab-ci: add a meson vulkan build Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-20 19:26:53 +08:00
gitlab-ci: Use separate arm64 build/test docker images The image used for test jobs is only about 1/6 as big as before, which may help avoid some issues with some of the test boards. Inspired by https://gitlab.freedesktop.org/mesa/mesa/issues/2046 . v2: * Leave LIBDRM_VERSION at 2.4.99 (Daniel Stone) * Delete more build artifacts from dEQP tree (Daniel Stone) v3: * Set LD_LIBRARY_PATH for ldd Acked-by: Daniel Stone <daniels@collabora.com> # v2 Reviewed-by: Eric Anholt <eric@anholt.net> # Except for the ldd line
2019-11-04 16:54:09 +08:00
debian-10-test:arm64:
extends:
- .debian@container-ifnot-exists@arm64v8
- .container
variables:
DEBIAN_TAG: "$DEBIAN_ARM64_TEST_TAG"
DEBIAN_EXEC: 'bash .gitlab-ci/debian-arm64-test-install.sh'
gitlab-ci: set a common job parent for container stage While at it, rename to singular "container" for consistency. Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2019-10-15 06:04:14 +08:00
gitlab-ci: add a meson vulkan build Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-20 19:26:53 +08:00
# BUILD
gitlab-ci: refactor out some common stuff for Windows and Linux Reviewed-by: Eric Engestrom <eric@engestrom.ch>
2019-10-24 05:21:31 +08:00
# Shared between windows and Linux
.build-common:
gitlab-ci: set a common job parent for build stage Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2019-10-15 06:52:58 +08:00
extends: .ci-run-policy
gitlab-ci: rename stages to something simpler Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2019-09-12 01:51:46 +08:00
stage: build
gitlab-ci: add a meson vulkan build Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-20 19:26:53 +08:00
artifacts:
gitlab-ci: Only keep the build logs as artifacts. On a build failure, we were tarring up the whole ccache directory, build.ninja, build products, etc. This was over 400MB compressed on a recent early meson-main build failure, which fd.o then has to hang on to for 4 weeks. The build logs are probably the interesting part, are potentially useful regardless ("how did CI's build flags differ from mine?"), and are <500k uncompressed on my personal meson build. Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
2019-07-25 00:27:48 +08:00
when: always
paths:
- _build/meson-logs/*.txt
# scons:
gitlab-ci: Fix scons build directory path Fixes: dd3d0b2897b8 "gitlab-ci: Only keep the build logs as artifacts." Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-07-26 18:20:41 +08:00
- build/*/config.log
gitlab-ci: Add a shader-db run using v3d on drm-shim. This provides significant compiler coverage during CI at a fairly low cost in CPU time (~17s per thread for 4 threads on gst-gitlab-htz-runner3). I'm leaving wget in the docker image, as once this is in master I'm planning on having an automatic shader-db comparison between master and the branch included in the artifacts. I also haven't done freedreno yet, because it has some races when run in multithreaded mode that I'm still tracking down. Reviewed-by: Eric Engestrom <eric@engestrom.ch>
2019-04-11 06:59:12 +08:00
- shader-db
gitlab-ci: refactor out some common stuff for Windows and Linux Reviewed-by: Eric Engestrom <eric@engestrom.ch>
2019-10-24 05:21:31 +08:00
# Just Linux
.build-linux:
extends: .build-common
cache:
key: ${CI_JOB_NAME}
paths:
- ccache
gitlab-ci: Install most packages from Debian buster We now use the C frontend of GCC 8 instead of 6 (required tweaking the before_script for the clang job). We cannot use the C++ frontend of GCC 7 or newer yet, because upstream GCC 7 changed some C++ name mangling stuff in backwards incompatible ways, and LLVM < 6.0 packages aren't available in buster. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-04-05 00:01:27 +08:00
variables:
CCACHE_COMPILERCHECK: "content"
gitlab-ci: use ccache to speed up builds Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-02-13 00:59:27 +08:00
# Use ccache transparently, and print stats before/after
before_script:
- export PATH="/usr/lib/ccache:$PATH"
- export CCACHE_BASEDIR="$PWD"
Revert "ci: Switch over to an autoscaling GKE cluster for builds." This reverts commit c9df92bf795af878c38538c85f781291c78ec513. It turns out that gitlab-runner uses kubernetes all wrong, spawning Pods and sshing into them to run the script instead of Jobs containing the script to run. This means that when anything goes wrong with the pod (autoscale, preemption, VM maintenance, cluster reconfiguration), the job fails and only sometimes gets handled as a runner system failure. Even worse, due to bugs in either the runner or k8s itself, some classes of timeout-related failure end up not being reported as failures, and the job will incorrectly report success! Disable using the "autoscale" cluster until we can do something else (docker-machine instead of k8s, or the custom third-party k8s-native runner). Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Acked-by: Daniel Stone <daniels@collabora.com>
2019-11-07 03:14:14 +08:00
- export CCACHE_DIR="$PWD/ccache"
- ccache --max-size=1500M
- ccache --zero-stats || true
gitlab-ci: use ccache to speed up builds Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-02-13 00:59:27 +08:00
- ccache --show-stats || true
after_script:
Revert "ci: Switch over to an autoscaling GKE cluster for builds." This reverts commit c9df92bf795af878c38538c85f781291c78ec513. It turns out that gitlab-runner uses kubernetes all wrong, spawning Pods and sshing into them to run the script instead of Jobs containing the script to run. This means that when anything goes wrong with the pod (autoscale, preemption, VM maintenance, cluster reconfiguration), the job fails and only sometimes gets handled as a runner system failure. Even worse, due to bugs in either the runner or k8s itself, some classes of timeout-related failure end up not being reported as failures, and the job will incorrectly report success! Disable using the "autoscale" cluster until we can do something else (docker-machine instead of k8s, or the custom third-party k8s-native runner). Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Acked-by: Daniel Stone <daniels@collabora.com>
2019-11-07 03:14:14 +08:00
- export CCACHE_DIR="$PWD/ccache"
gitlab-ci: use ccache to speed up builds Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-02-13 00:59:27 +08:00
- ccache --show-stats
gitlab-ci: add a meson vulkan build Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-20 19:26:53 +08:00
gitlab-ci: Add a job for meson on windows This adds a new CI job that runs on windows with MSVC. It currently builds softpipe and osmesa, and runs the related unit tests. It does rely on meson's wraps for zlib, but I've set up caching of the wrap dependencies so hopefully that wont be a problem. I really wanted to user powershell for this, but there just isn't an easy way to do that, it's much easier to use batch scripts, so thats what I used. The leading `/` for .gitlab-ci/lava... must be removed because windows doesn't understand it, and when it reads the file the job ends in error. Reviewed-by: Eric Engestrom <eric@engestrom.ch>
2019-10-24 05:36:19 +08:00
.build-windows:
extends: .build-common
tags:
- mesa-windows
cache:
key: ${CI_JOB_NAME}
paths:
- subprojects/packagecache
gitlab-ci: add a meson vulkan build Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-20 19:26:53 +08:00
.meson-build:
gitlab-ci: set a common job parent for build stage Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2019-10-15 06:52:58 +08:00
extends:
gitlab-ci: refactor out some common stuff for Windows and Linux Reviewed-by: Eric Engestrom <eric@engestrom.ch>
2019-10-24 05:21:31 +08:00
- .build-linux
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
- .use-debian-10:amd64
gitlab-ci: use ccache to speed up builds Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-02-13 00:59:27 +08:00
script:
gitlab-ci: Move meson job script to separate file No functional change intended (except for no longer running meson --version separately, as the version appears early in meson's output anyway). Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-05-03 16:49:43 +08:00
- .gitlab-ci/meson-build.sh
gitlab-ci: add a meson vulkan build Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-20 19:26:53 +08:00
gitlab-ci: add a scons no-llvm build Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-23 23:46:10 +08:00
.scons-build:
gitlab-ci: set a common job parent for build stage Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2019-10-15 06:52:58 +08:00
extends:
gitlab-ci: refactor out some common stuff for Windows and Linux Reviewed-by: Eric Engestrom <eric@engestrom.ch>
2019-10-24 05:21:31 +08:00
- .build-linux
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
- .use-debian-10:amd64
gitlab-ci: add a scons no-llvm build Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-23 23:46:10 +08:00
variables:
Revert "ci: Switch over to an autoscaling GKE cluster for builds." This reverts commit c9df92bf795af878c38538c85f781291c78ec513. It turns out that gitlab-runner uses kubernetes all wrong, spawning Pods and sshing into them to run the script instead of Jobs containing the script to run. This means that when anything goes wrong with the pod (autoscale, preemption, VM maintenance, cluster reconfiguration), the job fails and only sometimes gets handled as a runner system failure. Even worse, due to bugs in either the runner or k8s itself, some classes of timeout-related failure end up not being reported as failures, and the job will incorrectly report success! Disable using the "autoscale" cluster until we can do something else (docker-machine instead of k8s, or the custom third-party k8s-native runner). Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Acked-by: Daniel Stone <daniels@collabora.com>
2019-11-07 03:14:14 +08:00
SCONSFLAGS: "-j4"
gitlab-ci: add a scons no-llvm build Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-23 23:46:10 +08:00
script:
gitlab-ci: Move scons build/test commands to a separate shell script Preparatory, no functional change intended. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-09-12 17:34:43 +08:00
- .gitlab-ci/scons-build.sh
gitlab-ci: add a scons no-llvm build Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-23 23:46:10 +08:00
gitlab-ci: Move up meson-main job definition In order to increase the chance of it running early. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-08-28 18:01:02 +08:00
meson-main:
gitlab-ci: Use multiple inheritance instead of YAML references Support for multiple inheritance was added to GitLab recently. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-06 23:35:52 +08:00
extends:
- .meson-build
- .ci-deqp-artifacts
gitlab-ci: Move up meson-main job definition In order to increase the chance of it running early. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-08-28 18:01:02 +08:00
variables:
UNWIND: "true"
DRI_LOADERS: >
-D glx=dri
-D gbm=true
-D egl=true
-D platforms=x11,wayland,drm,surfaceless
DRI_DRIVERS: "i915,i965,r100,r200,nouveau"
GALLIUM_ST: >
-D dri3=true
-D gallium-extra-hud=true
-D gallium-vdpau=true
-D gallium-xvmc=true
-D gallium-omx=bellagio
-D gallium-va=true
-D gallium-xa=true
-D gallium-nine=true
-D gallium-opencl=disabled
gitlab-ci: also build Zink on CI This prevents accidentally breaking the driver-build while working on other drivers. Signed-off-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
2019-10-22 15:08:11 +08:00
GALLIUM_DRIVERS: "iris,nouveau,kmsro,r300,r600,freedreno,swrast,svga,v3d,vc4,virgl,etnaviv,panfrost,lima,zink"
gitlab-ci: Move up meson-main job definition In order to increase the chance of it running early. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-08-28 18:01:02 +08:00
LLVM_VERSION: "7"
EXTRA_OPTION: >
-D osmesa=gallium
-D tools=all
BUILDTYPE: "debugoptimized"
gitlab-ci: Move artifact preparation to separate script It's currently only needed for the meson-main and meson-arm64 jobs, not the other meson build jobs. Also remove MESON_SHADERDB, just run .gitlab-ci/run-shader-db.sh directly from the meson-main job. v2: * Also run prepare-artifacts.sh in meson-arm64 script v3: * Move tarball creation into the new script as well, as it prevented ccache --show-stats from running in after_script Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> # v1 Reviewed-by: Eric Anholt <eric@anholt.net>
2019-10-24 00:42:53 +08:00
script:
- .gitlab-ci/meson-build.sh
- .gitlab-ci/run-shader-db.sh
- .gitlab-ci/prepare-artifacts.sh
gitlab-ci: Move up meson-main job definition In order to increase the chance of it running early. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-08-28 18:01:02 +08:00
gitlab-ci: Move up meson-arm64 job definition This might allow the arm64 tests to start running earlier. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-13 17:59:43 +08:00
.meson-cross:
extends:
- .meson-build
variables:
UNWIND: "false"
DRI_LOADERS: >
-D glx=disabled
-D gbm=false
-D egl=true
-D platforms=surfaceless
-D osmesa=none
GALLIUM_ST: >
-D dri3=false
-D gallium-vdpau=false
-D gallium-xvmc=false
-D gallium-omx=disabled
-D gallium-va=false
-D gallium-xa=false
-D gallium-nine=false
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
.meson-arm:
gitlab-ci: Move up meson-arm64 job definition This might allow the arm64 tests to start running earlier. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-13 17:59:43 +08:00
extends: .meson-cross
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
image: $DEBIAN_ARM64_IMAGE
gitlab-ci: Move up meson-arm64 job definition This might allow the arm64 tests to start running earlier. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-13 17:59:43 +08:00
variables:
VULKAN_DRIVERS: freedreno
gitlab-ci: Enable llvmpipe in ARM build jobs v2: * Use LLVM 8 from buster-backports v3: * Use LLVM 7 again for armhf, llvmpipe is still broken there with LLVM 8 Acked-by: Eric Engestrom <eric.engestrom@intel.com>
2019-10-09 01:48:41 +08:00
GALLIUM_DRIVERS: "etnaviv,freedreno,kmsro,lima,nouveau,panfrost,swrast,tegra,v3d,vc4"
gitlab-ci: Move up meson-arm64 job definition This might allow the arm64 tests to start running earlier. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-13 17:59:43 +08:00
EXTRA_OPTION: >
-D I-love-half-baked-turnips=true
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
needs:
- debian-10:arm64
tags:
- aarch64
meson-armhf:
extends: .meson-arm
variables:
CROSS: armhf
gitlab-ci: Enable llvmpipe in ARM build jobs v2: * Use LLVM 8 from buster-backports v3: * Use LLVM 7 again for armhf, llvmpipe is still broken there with LLVM 8 Acked-by: Eric Engestrom <eric.engestrom@intel.com>
2019-10-09 01:48:41 +08:00
LLVM_VERSION: "7"
gitlab-ci: Move up meson-arm64 job definition This might allow the arm64 tests to start running earlier. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-13 17:59:43 +08:00
meson-arm64:
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
extends:
- .meson-arm
- .ci-deqp-artifacts
gitlab-ci: Move up meson-arm64 job definition This might allow the arm64 tests to start running earlier. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-13 17:59:43 +08:00
variables:
BUILDTYPE: "debugoptimized"
gitlab-ci: build RADV on ARM64 The ARMHF LLVM package is LLVM 7 but RADV requires LLVM 8. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-11-12 21:25:16 +08:00
VULKAN_DRIVERS: "freedreno,amd"
gitlab-ci: Move artifact preparation to separate script It's currently only needed for the meson-main and meson-arm64 jobs, not the other meson build jobs. Also remove MESON_SHADERDB, just run .gitlab-ci/run-shader-db.sh directly from the meson-main job. v2: * Also run prepare-artifacts.sh in meson-arm64 script v3: * Move tarball creation into the new script as well, as it prevented ccache --show-stats from running in after_script Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> # v1 Reviewed-by: Eric Anholt <eric@anholt.net>
2019-10-24 00:42:53 +08:00
script:
- .gitlab-ci/meson-build.sh
- .gitlab-ci/prepare-artifacts.sh
gitlab-ci: Move up meson-arm64 job definition This might allow the arm64 tests to start running earlier. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-13 17:59:43 +08:00
gitlab-ci: List some longer-running jobs before others of the same stage This increases the chance of them running earlier, which can have an impact on the total duration of the pipeline. v2: * Minor style fix-up to moved comment (Eric Anholt) Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Acked-by: Eric Anholt <eric@anholt.net>
2019-03-20 22:58:31 +08:00
# NOTE: Building SWR is 2x (yes two) times slower than all the other
# gallium drivers combined.
# Start this early so that it doesn't limit the total run time.
gitlab-ci: merge several meson jobs Merge the following into `meson-main`/`meson-loader-classic-dri`/ `meson-gallium-swr`: - meson-vulkan - meson-gallium-drivers-other - meson-gallium-st-other Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> [ Michel Dänzer ] * Rebase and fix up commit log. * Don't set VULKAN_DRIVERS in meson-loader-classic-dri. * Remove extraneous whitespace. * Squash in follow-up fixes. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> [ anholt] * Add a note why nine and swrast landed where they did. * Switch from s/meson-vulkan/meson-main/ to s/meson-loader-classic-dri/meson-main/ which I think was the original intent Reviewed-by: Eric Anholt <eric@anholt.net> Acked-by: Eric Engestrom <eric.engestrom@intel.com> (anholt changes) Acked-by: Dylan Baker <dylan@pnwbakers.com>
2019-03-09 00:33:07 +08:00
#
gitlab-ci: Move around which builds cover which swrast. I want to enable CI of llvmpipe out of the meson-main build. So, kick classic swrast/osmesa to meson-i386, then promote llvmpipe to meson-main (along with nine, now that classic osmesa isn't keeping it out of there). Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-08-08 05:05:51 +08:00
# We also stick the glvnd build here, since we want non-glvnd in
# meson-main for actual driver CI.
gitlab-ci: merge meson-glvnd into meson-swr There's no need to have a whole build just for that flag, we can add it to any build. v2: Add a note about why we put glvnd where we did (by anholt). Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> (v2) Acked-by: Dylan Baker <dylan@pnwbakers.com>
2019-04-17 00:06:53 +08:00
meson-swr-glvnd:
gitlab-ci: List some longer-running jobs before others of the same stage This increases the chance of them running earlier, which can have an impact on the total duration of the pipeline. v2: * Minor style fix-up to moved comment (Eric Anholt) Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Acked-by: Eric Anholt <eric@anholt.net>
2019-03-20 22:58:31 +08:00
extends: .meson-build
variables:
UNWIND: "true"
DRI_LOADERS: >
gitlab-ci: merge meson-glvnd into meson-swr There's no need to have a whole build just for that flag, we can add it to any build. v2: Add a note about why we put glvnd where we did (by anholt). Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> (v2) Acked-by: Dylan Baker <dylan@pnwbakers.com>
2019-04-17 00:06:53 +08:00
-D glvnd=true
-D egl=true
gitlab-ci: List some longer-running jobs before others of the same stage This increases the chance of them running earlier, which can have an impact on the total duration of the pipeline. v2: * Minor style fix-up to moved comment (Eric Anholt) Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Acked-by: Eric Anholt <eric@anholt.net>
2019-03-20 22:58:31 +08:00
GALLIUM_ST: >
gitlab-ci: merge several meson jobs Merge the following into `meson-main`/`meson-loader-classic-dri`/ `meson-gallium-swr`: - meson-vulkan - meson-gallium-drivers-other - meson-gallium-st-other Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> [ Michel Dänzer ] * Rebase and fix up commit log. * Don't set VULKAN_DRIVERS in meson-loader-classic-dri. * Remove extraneous whitespace. * Squash in follow-up fixes. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> [ anholt] * Add a note why nine and swrast landed where they did. * Switch from s/meson-vulkan/meson-main/ to s/meson-loader-classic-dri/meson-main/ which I think was the original intent Reviewed-by: Eric Anholt <eric@anholt.net> Acked-by: Eric Engestrom <eric.engestrom@intel.com> (anholt changes) Acked-by: Dylan Baker <dylan@pnwbakers.com>
2019-03-09 00:33:07 +08:00
-D dri3=true
gitlab-ci: List some longer-running jobs before others of the same stage This increases the chance of them running earlier, which can have an impact on the total duration of the pipeline. v2: * Minor style fix-up to moved comment (Eric Anholt) Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Acked-by: Eric Anholt <eric@anholt.net>
2019-03-20 22:58:31 +08:00
-D gallium-vdpau=false
-D gallium-xvmc=false
-D gallium-omx=disabled
-D gallium-va=false
-D gallium-xa=false
gitlab-ci: Move around which builds cover which swrast. I want to enable CI of llvmpipe out of the meson-main build. So, kick classic swrast/osmesa to meson-i386, then promote llvmpipe to meson-main (along with nine, now that classic osmesa isn't keeping it out of there). Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-08-08 05:05:51 +08:00
-D gallium-nine=false
gitlab-ci: List some longer-running jobs before others of the same stage This increases the chance of them running earlier, which can have an impact on the total duration of the pipeline. v2: * Minor style fix-up to moved comment (Eric Anholt) Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Acked-by: Eric Anholt <eric@anholt.net>
2019-03-20 22:58:31 +08:00
-D gallium-opencl=disabled
gitlab-ci: Move around which builds cover which swrast. I want to enable CI of llvmpipe out of the meson-main build. So, kick classic swrast/osmesa to meson-i386, then promote llvmpipe to meson-main (along with nine, now that classic osmesa isn't keeping it out of there). Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-08-08 05:05:51 +08:00
GALLIUM_DRIVERS: "swr,iris"
gitlab-ci: List some longer-running jobs before others of the same stage This increases the chance of them running earlier, which can have an impact on the total duration of the pipeline. v2: * Minor style fix-up to moved comment (Eric Anholt) Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Acked-by: Eric Anholt <eric@anholt.net>
2019-03-20 22:58:31 +08:00
LLVM_VERSION: "6.0"
meson-clang:
extends: .meson-build
variables:
UNWIND: "true"
DRI_DRIVERS: "auto"
GALLIUM_DRIVERS: "auto"
gitlab-ci: build vulkan drivers in clang build Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com>
2019-05-01 19:09:26 +08:00
VULKAN_DRIVERS: intel,amd,freedreno
gitlab-ci: Use clang 8 instead of 7 Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-04-05 16:36:29 +08:00
CC: "ccache clang-8"
CXX: "ccache clang++-8"
gitlab-ci: List some longer-running jobs before others of the same stage This increases the chance of them running earlier, which can have an impact on the total duration of the pipeline. v2: * Minor style fix-up to moved comment (Eric Anholt) Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Acked-by: Eric Anholt <eric@anholt.net>
2019-03-20 22:58:31 +08:00
gitlab-ci: Disable meson-windows job for the time being It needs a CI runner carrying the mesa-windows tag, but there's none available currently.
2019-10-30 16:38:20 +08:00
.meson-windows:
gitlab-ci: Add a job for meson on windows This adds a new CI job that runs on windows with MSVC. It currently builds softpipe and osmesa, and runs the related unit tests. It does rely on meson's wraps for zlib, but I've set up caching of the wrap dependencies so hopefully that wont be a problem. I really wanted to user powershell for this, but there just isn't an easy way to do that, it's much easier to use batch scripts, so thats what I used. The leading `/` for .gitlab-ci/lava... must be removed because windows doesn't understand it, and when it reads the file the job ends in error. Reviewed-by: Eric Engestrom <eric@engestrom.ch>
2019-10-24 05:36:19 +08:00
extends:
- .build-windows
before_script:
- $ENV:ARCH = "x86"
- $ENV:VERSION = "2019\Community"
script:
- cmd /C .gitlab-ci\meson-build.bat
gitlab-ci: Reorder jobs a bit to be generally ordered longer => shorter This makes the longer jobs likely to run earlier, which can help the overall pipeline duration. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-05-04 00:19:25 +08:00
scons-swr:
extends: .scons-build
gitlab-ci: add a meson vulkan build Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-20 19:26:53 +08:00
variables:
gitlab-ci: Reorder jobs a bit to be generally ordered longer => shorter This makes the longer jobs likely to run earlier, which can help the overall pipeline duration. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-05-04 00:19:25 +08:00
SCONS_TARGET: "swr=1"
SCONS_CHECK_COMMAND: "true"
LLVM_VERSION: "6.0"
scons-win64:
extends: .scons-build
variables:
SCONS_TARGET: platform=windows machine=x86_64
SCONS_CHECK_COMMAND: "true"
gitlab-ci: add a make vulkan build Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-21 17:42:37 +08:00
gitlab-ci: Build clover against all supported versions of LLVM And consolidate it all into a single job. It doesn't take much longer than a single version, thanks to ccache. Overall, this single job might be faster or at least use fewer CPU cycles than the two jobs before, while covering thrice as many versions of LLVM. v2: * Move "rm -rf _build" to meson-build.sh. * Set GALLIUM_DRIVERS the same way both times in the meson-clover job, for symmetry. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-05-03 16:58:48 +08:00
meson-clover:
gitlab-ci: add meson gallium ST Clover (LLVM 5.0) build Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-29 02:05:22 +08:00
extends: .meson-build
variables:
UNWIND: "true"
DRI_LOADERS: >
-D glx=disabled
-D egl=false
-D gbm=false
GALLIUM_ST: >
-D dri3=false
-D gallium-vdpau=false
-D gallium-xvmc=false
-D gallium-omx=disabled
-D gallium-va=false
-D gallium-xa=false
-D gallium-nine=false
-D gallium-opencl=icd
gitlab-ci: Build clover against all supported versions of LLVM And consolidate it all into a single job. It doesn't take much longer than a single version, thanks to ccache. Overall, this single job might be faster or at least use fewer CPU cycles than the two jobs before, while covering thrice as many versions of LLVM. v2: * Move "rm -rf _build" to meson-build.sh. * Set GALLIUM_DRIVERS the same way both times in the meson-clover job, for symmetry. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-05-03 16:58:48 +08:00
script:
- export GALLIUM_DRIVERS="r600,radeonsi"
- .gitlab-ci/meson-build.sh
gitlab-ci: bump LLVM to 8 for meson-vulkan and meson-clover To fix pipeline builds. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-08-21 17:45:25 +08:00
- LLVM_VERSION=8 .gitlab-ci/meson-build.sh
gitlab-ci: Build clover against all supported versions of LLVM And consolidate it all into a single job. It doesn't take much longer than a single version, thanks to ccache. Overall, this single job might be faster or at least use fewer CPU cycles than the two jobs before, while covering thrice as many versions of LLVM. v2: * Move "rm -rf _build" to meson-build.sh. * Set GALLIUM_DRIVERS the same way both times in the meson-clover job, for symmetry. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-05-03 16:58:48 +08:00
- export GALLIUM_DRIVERS="i915,r600"
gitlab-ci: Create separate docker images for Debian stretch & buster Pros: * Less fragile due to not mixing packages from stretch and buster * No longer need to use third-party LLVM packages * The buster image now uses GCC 8 for C++ as well (previously 6 for C++, 8 for C), allowing to drop some hacks Con: * The stretch image now only uses GCC 6 for C as well as C++ * Need separate jobs for testing old LLVM versions Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-09-06 23:04:47 +08:00
- LLVM_VERSION=6.0 .gitlab-ci/meson-build.sh
- LLVM_VERSION=7 .gitlab-ci/meson-build.sh
meson-clover-old-llvm:
gitlab-ci: Declare needs: for stretch docker image This allows the *-old-llvm jobs to run before the buster docker images are ready. v2: * Use - list syntax instead of [] (Eric Engestrom) Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-18 22:17:01 +08:00
extends:
- meson-clover
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
- .use-debian-9:amd64
gitlab-ci: Create separate docker images for Debian stretch & buster Pros: * Less fragile due to not mixing packages from stretch and buster * No longer need to use third-party LLVM packages * The buster image now uses GCC 8 for C++ as well (previously 6 for C++, 8 for C), allowing to drop some hacks Con: * The stretch image now only uses GCC 6 for C as well as C++ * Need separate jobs for testing old LLVM versions Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-09-06 23:04:47 +08:00
variables:
UNWIND: "false"
DRI_LOADERS: >
-D glx=disabled
-D egl=false
-D gbm=false
-D platforms=drm,surfaceless
GALLIUM_DRIVERS: "i915,r600"
script:
gitlab-ci: Build clover against all supported versions of LLVM And consolidate it all into a single job. It doesn't take much longer than a single version, thanks to ccache. Overall, this single job might be faster or at least use fewer CPU cycles than the two jobs before, while covering thrice as many versions of LLVM. v2: * Move "rm -rf _build" to meson-build.sh. * Set GALLIUM_DRIVERS the same way both times in the meson-clover job, for symmetry. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-05-03 16:58:48 +08:00
- LLVM_VERSION=3.9 .gitlab-ci/meson-build.sh
- LLVM_VERSION=4.0 .gitlab-ci/meson-build.sh
- LLVM_VERSION=5.0 .gitlab-ci/meson-build.sh
gitlab-ci: add meson gallium ST Clover (LLVM 7.0) build Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-29 02:09:24 +08:00
gitlab-ci: Reorder jobs a bit to be generally ordered longer => shorter This makes the longer jobs likely to run earlier, which can help the overall pipeline duration. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-05-04 00:19:25 +08:00
meson-vulkan:
extends: .meson-build
variables:
UNWIND: "false"
DRI_LOADERS: >
-D glx=disabled
-D gbm=false
-D egl=false
-D platforms=x11,wayland,drm
-D osmesa=none
GALLIUM_ST: >
-D dri3=true
-D gallium-vdpau=false
-D gallium-xvmc=false
-D gallium-omx=disabled
-D gallium-va=false
-D gallium-xa=false
-D gallium-nine=false
-D gallium-opencl=disabled
gitlab-ci: Enable UBSan for the meson-vulkan job It doesn't report any errors now. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Adam Jackson <ajax@redhat.com>
2019-09-25 18:56:58 +08:00
-D b_sanitize=undefined
-D c_args=-fno-sanitize-recover=all
-D cpp_args=-fno-sanitize-recover=all
UBSAN_OPTIONS: "print_stacktrace=1"
gitlab-ci: Reorder jobs a bit to be generally ordered longer => shorter This makes the longer jobs likely to run earlier, which can help the overall pipeline duration. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-05-04 00:19:25 +08:00
VULKAN_DRIVERS: intel,amd,freedreno
gitlab-ci: bump LLVM to 8 for meson-vulkan and meson-clover To fix pipeline builds. Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-08-21 17:45:25 +08:00
LLVM_VERSION: "8"
gitlab-ci: add the vulkan overlay layer to the vulkan build Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
2019-05-09 00:17:23 +08:00
EXTRA_OPTION: >
-D vulkan-overlay-layer=true
gitlab-ci: Reorder jobs a bit to be generally ordered longer => shorter This makes the longer jobs likely to run earlier, which can help the overall pipeline duration. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-05-04 00:19:25 +08:00
gitlab-ci: Move around which builds cover which swrast. I want to enable CI of llvmpipe out of the meson-main build. So, kick classic swrast/osmesa to meson-i386, then promote llvmpipe to meson-main (along with nine, now that classic osmesa isn't keeping it out of there). Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-08-08 05:05:51 +08:00
# While the main point of this build is testing the i386 cross build,
# we also use this one to test some other options that are exclusive
# with meson-main's choices (classic swrast and osmesa)
gitlab-ci: Build i386 and ARM drivers in surfaceless mode. I don't particularly care about getting x86/ARM cross-build coverage of all the window systems, but we do want to be building src/mesa/ (for x86 asm) and gallium drivers (for vc4 NEON asm). I'm also hoping to use these build products for testing freedreno on actual HW (which we do using surfaceless). This increases the docker image from 1.4G to 1.5G. Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Acked-by: Eric Engestrom <eric@engestrom.ch>
2019-07-12 03:58:28 +08:00
meson-i386:
extends: .meson-cross
variables:
gitlab-ci: simplify $CROSS option Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2019-08-10 06:46:50 +08:00
CROSS: i386
gitlab-ci: Build i386 and ARM drivers in surfaceless mode. I don't particularly care about getting x86/ARM cross-build coverage of all the window systems, but we do want to be building src/mesa/ (for x86 asm) and gallium drivers (for vc4 NEON asm). I'm also hoping to use these build products for testing freedreno on actual HW (which we do using surfaceless). This increases the docker image from 1.4G to 1.5G. Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Acked-by: Eric Engestrom <eric@engestrom.ch>
2019-07-12 03:58:28 +08:00
VULKAN_DRIVERS: intel
gitlab-ci: Move around which builds cover which swrast. I want to enable CI of llvmpipe out of the meson-main build. So, kick classic swrast/osmesa to meson-i386, then promote llvmpipe to meson-main (along with nine, now that classic osmesa isn't keeping it out of there). Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-08-08 05:05:51 +08:00
DRI_DRIVERS: "swrast"
GALLIUM_DRIVERS: "iris"
gitlab-ci: Build i386 and ARM drivers in surfaceless mode. I don't particularly care about getting x86/ARM cross-build coverage of all the window systems, but we do want to be building src/mesa/ (for x86 asm) and gallium drivers (for vc4 NEON asm). I'm also hoping to use these build products for testing freedreno on actual HW (which we do using surfaceless). This increases the docker image from 1.4G to 1.5G. Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Acked-by: Eric Engestrom <eric@engestrom.ch>
2019-07-12 03:58:28 +08:00
EXTRA_OPTION: >
-D vulkan-overlay-layer=true
gitlab-ci: Move around which builds cover which swrast. I want to enable CI of llvmpipe out of the meson-main build. So, kick classic swrast/osmesa to meson-i386, then promote llvmpipe to meson-main (along with nine, now that classic osmesa isn't keeping it out of there). Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-08-08 05:05:51 +08:00
-D llvm=false
-D osmesa=classic
gitlab-ci: Build i386 and ARM drivers in surfaceless mode. I don't particularly care about getting x86/ARM cross-build coverage of all the window systems, but we do want to be building src/mesa/ (for x86 asm) and gallium drivers (for vc4 NEON asm). I'm also hoping to use these build products for testing freedreno on actual HW (which we do using surfaceless). This increases the docker image from 1.4G to 1.5G. Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Acked-by: Eric Engestrom <eric@engestrom.ch>
2019-07-12 03:58:28 +08:00
Revert "gitlab-ci: Disable meson-mingw32-x86_64 job again for now" This reverts commit d60b8679a46212d992dcd94b9d3eeebfcff3f00a. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-10-12 00:04:14 +08:00
meson-mingw32-x86_64:
gitlab-ci: Add a mingw x86_64 job Acked-by: Eric Engestrom <eric.engestrom@intel.com> (v1) Acked-by: Kristian H. Kristensen <hoegsberg@google.com>
2019-09-20 01:21:51 +08:00
extends: .meson-build
variables:
UNWIND: "false"
DRI_DRIVERS: ""
GALLIUM_DRIVERS: "swrast"
EXTRA_OPTION: >
-Dllvm=false
-Dosmesa=gallium
--cross-file=.gitlab-ci/x86_64-w64-mingw32
gitlab-ci: Merge scons-nollvm and scons-llvm jobs The new job tests scons without LLVM and with all LLVM versions >= 6.0. Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-09-12 17:45:13 +08:00
scons:
gitlab-ci: add scons llvm 3.5 build Signed-off-by: Eric Engestrom <eric.engestrom@intel.com>
2019-01-29 00:30:36 +08:00
extends: .scons-build
variables:
SCONS_TARGET: "llvm=1"
scons: Print a deprecation warning about using scons on not windows At this point meson should be able to handle all of the non-windows platforms just fine; we'd like to be able to stop maintaining scons for those platforms sooner than later. Reviewed-by: Eric Anholt <eric@anholt.net>
2019-10-22 00:29:23 +08:00
SCONS_CHECK_COMMAND: "scons llvm=1 force_scons=1 check"
gitlab-ci: Test scons with all LLVM versions Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-09-12 17:38:06 +08:00
script:
scons: Print a deprecation warning about using scons on not windows At this point meson should be able to handle all of the non-windows platforms just fine; we'd like to be able to stop maintaining scons for those platforms sooner than later. Reviewed-by: Eric Anholt <eric@anholt.net>
2019-10-22 00:29:23 +08:00
- SCONS_TARGET="" SCONS_CHECK_COMMAND="scons check force_scons=1" .gitlab-ci/scons-build.sh
gitlab-ci: Test scons with all LLVM versions Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-09-12 17:38:06 +08:00
- LLVM_VERSION=6.0 .gitlab-ci/scons-build.sh
- LLVM_VERSION=7 .gitlab-ci/scons-build.sh
- LLVM_VERSION=8 .gitlab-ci/scons-build.sh
gitlab-ci: Create separate docker images for Debian stretch & buster Pros: * Less fragile due to not mixing packages from stretch and buster * No longer need to use third-party LLVM packages * The buster image now uses GCC 8 for C++ as well (previously 6 for C++, 8 for C), allowing to drop some hacks Con: * The stretch image now only uses GCC 6 for C as well as C++ * Need separate jobs for testing old LLVM versions Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-09-06 23:04:47 +08:00
scons-old-llvm:
gitlab-ci: Declare needs: for stretch docker image This allows the *-old-llvm jobs to run before the buster docker images are ready. v2: * Use - list syntax instead of [] (Eric Engestrom) Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-18 22:17:01 +08:00
extends:
- scons
gitlab-ci: Use native aarch64 runner for ARM build jobs This allows running the regression tests. One downside is that we can't easily build the Vulkan overlay layer, because only x86 binaries of the glslang validator are available. If that's important, we could either use those binaries via qemu, or build it from source. v2: * Add :amd64 suffix to existing debian-9/10 job names (Eric Engestrom) Acked-by: Eric Engestrom <eric.engestrom@intel.com> # v1
2019-10-09 01:46:11 +08:00
- .use-debian-9:amd64
gitlab-ci: Test scons with all LLVM versions Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-09-12 17:38:06 +08:00
script:
- LLVM_VERSION=3.9 .gitlab-ci/scons-build.sh
- LLVM_VERSION=4.0 .gitlab-ci/scons-build.sh
- LLVM_VERSION=5.0 .gitlab-ci/scons-build.sh
gitlab-ci: Run the GLES2 CTS on llvmpipe. This is the start of doing CTS tests on merges to Mesa master. We use the surfaceless platform so that we don't need to bother bringing up weston or X11. The surface size is kept low to reduce runtime, but this comes at the cost of many rendering tests skipping due to too-small render targets (as we see the impact of Mesa on the shared runner pool, we can reevaluate this and what set of CTS tests we want to run). We split the job up across 4 runners (each at 4 llvmpipe threads), so that the job can load-balance across our shared runners and finish sooner (since dEQP is very single-thread-performance bound). Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-06-29 07:35:32 +08:00
gitlab-ci: set a common job parent for test stage Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2019-10-15 06:53:15 +08:00
.test:
extends:
gitlab-ci: Run piglit tests with llvmpipe One job for the quick_gl profile, one for the glslparser & quick_shader profiles (doing these together takes hardly any more time than quick_shader alone). v2: * Don't break lava tests v3: * Remove piglit test artifacts paths: * Exclude some quick_shader tests again: - Test whose result flips between pass/fail/skip - *@vs_in tests, as not the same one of these gets picked every time v4: * Do not list passing tests in .gitlab-ci/piglit/*.txt (Eric Anholt) * Include the test number summary in .gitlab-ci/piglit/*.txt * Completely disable generating any vs_in tests in the piglit build. * Remove some more unneded files from the piglit build tree. * Exclude quick_gl arb_gpu_shader5 tests; they were all skipped anyway, as llvmpipe doesn't support this extension yet, but occasionally they would spuriously fail instead. v5: * Set LD_LIBRARY_PATH, so we actually test the Mesa build from the pipeline... * Verify that wflinfo reports the expected Mesa version * Pass -noreset to Xvfb v6: * Don't use autoscale runners, run piglit with -j4 (Eric Anholt) Reviewed-by: Eric Anholt <eric@anholt.net>
2019-10-22 23:16:52 +08:00
- .ci-run-policy
gitlab-ci: Use separate docker images for x86 build/test jobs Same as was done for the ARM images before. This should make it less painful to update to newer dEQP / piglit as well as to make changes to the build/test environment. Reviewed-by: Eric Anholt <eric@anholt.net>
2019-11-06 01:52:24 +08:00
image: $DEBIAN_TEST_IMAGE
gitlab-ci: Run piglit tests with llvmpipe One job for the quick_gl profile, one for the glslparser & quick_shader profiles (doing these together takes hardly any more time than quick_shader alone). v2: * Don't break lava tests v3: * Remove piglit test artifacts paths: * Exclude some quick_shader tests again: - Test whose result flips between pass/fail/skip - *@vs_in tests, as not the same one of these gets picked every time v4: * Do not list passing tests in .gitlab-ci/piglit/*.txt (Eric Anholt) * Include the test number summary in .gitlab-ci/piglit/*.txt * Completely disable generating any vs_in tests in the piglit build. * Remove some more unneded files from the piglit build tree. * Exclude quick_gl arb_gpu_shader5 tests; they were all skipped anyway, as llvmpipe doesn't support this extension yet, but occasionally they would spuriously fail instead. v5: * Set LD_LIBRARY_PATH, so we actually test the Mesa build from the pipeline... * Verify that wflinfo reports the expected Mesa version * Pass -noreset to Xvfb v6: * Don't use autoscale runners, run piglit with -j4 (Eric Anholt) Reviewed-by: Eric Anholt <eric@anholt.net>
2019-10-22 23:16:52 +08:00
stage: test
gitlab-ci: set a common job parent for test stage Signed-off-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
2019-10-15 06:53:15 +08:00
variables:
gitlab-ci: Run piglit tests with llvmpipe One job for the quick_gl profile, one for the glslparser & quick_shader profiles (doing these together takes hardly any more time than quick_shader alone). v2: * Don't break lava tests v3: * Remove piglit test artifacts paths: * Exclude some quick_shader tests again: - Test whose result flips between pass/fail/skip - *@vs_in tests, as not the same one of these gets picked every time v4: * Do not list passing tests in .gitlab-ci/piglit/*.txt (Eric Anholt) * Include the test number summary in .gitlab-ci/piglit/*.txt * Completely disable generating any vs_in tests in the piglit build. * Remove some more unneded files from the piglit build tree. * Exclude quick_gl arb_gpu_shader5 tests; they were all skipped anyway, as llvmpipe doesn't support this extension yet, but occasionally they would spuriously fail instead. v5: * Set LD_LIBRARY_PATH, so we actually test the Mesa build from the pipeline... * Verify that wflinfo reports the expected Mesa version * Pass -noreset to Xvfb v6: * Don't use autoscale runners, run piglit with -j4 (Eric Anholt) Reviewed-by: Eric Anholt <eric@anholt.net>
2019-10-22 23:16:52 +08:00
GIT_STRATEGY: none # testing doesn't build anything from source
before_script:
gitlab-ci: Run the GLES2 CTS on llvmpipe. This is the start of doing CTS tests on merges to Mesa master. We use the surfaceless platform so that we don't need to bother bringing up weston or X11. The surface size is kept low to reduce runtime, but this comes at the cost of many rendering tests skipping due to too-small render targets (as we see the impact of Mesa on the shared runner pool, we can reevaluate this and what set of CTS tests we want to run). We split the job up across 4 runners (each at 4 llvmpipe threads), so that the job can load-balance across our shared runners and finish sooner (since dEQP is very single-thread-performance bound). Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-06-29 07:35:32 +08:00
# Note: Build dir (and thus install) may be dirty due to GIT_STRATEGY
- rm -rf install
- tar -xf artifacts/install.tar
gitlab-ci: Use separate arm64 build/test docker images The image used for test jobs is only about 1/6 as big as before, which may help avoid some issues with some of the test boards. Inspired by https://gitlab.freedesktop.org/mesa/mesa/issues/2046 . v2: * Leave LIBDRM_VERSION at 2.4.99 (Daniel Stone) * Delete more build artifacts from dEQP tree (Daniel Stone) v3: * Set LD_LIBRARY_PATH for ldd Acked-by: Daniel Stone <daniels@collabora.com> # v2 Reviewed-by: Eric Anholt <eric@anholt.net> # Except for the ldd line
2019-11-04 16:54:09 +08:00
- LD_LIBRARY_PATH=install/lib ldd install/lib/{*,dri/swrast_dri}.so
gitlab-ci: Run the GLES2 CTS on llvmpipe. This is the start of doing CTS tests on merges to Mesa master. We use the surfaceless platform so that we don't need to bother bringing up weston or X11. The surface size is kept low to reduce runtime, but this comes at the cost of many rendering tests skipping due to too-small render targets (as we see the impact of Mesa on the shared runner pool, we can reevaluate this and what set of CTS tests we want to run). We split the job up across 4 runners (each at 4 llvmpipe threads), so that the job can load-balance across our shared runners and finish sooner (since dEQP is very single-thread-performance bound). Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-06-29 07:35:32 +08:00
artifacts:
when: on_failure
name: "$CI_JOB_NAME-$CI_COMMIT_REF_NAME"
paths:
- results/
gitlab-ci: Move dependencies/needs for meson-main job to .deqp-test Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-13 17:13:12 +08:00
dependencies:
- meson-main
gitlab-ci: Explicitly list debian-10 in needs: for .deqp-test template Apparently needs: in a definition overwrites inherited ones. So .deqp-test effectively didn't declare needs: for debian-10, which means any jobs based on .deqp-test could spuriously run after the debian-10 job failed or was cancelled.
2019-10-22 17:19:17 +08:00
needs:
- meson-main
gitlab-ci: Use separate docker images for x86 build/test jobs Same as was done for the ARM images before. This should make it less painful to update to newer dEQP / piglit as well as to make changes to the build/test environment. Reviewed-by: Eric Anholt <eric@anholt.net>
2019-11-06 01:52:24 +08:00
- debian-10-test:amd64
gitlab-ci: Run the GLES2 CTS on llvmpipe. This is the start of doing CTS tests on merges to Mesa master. We use the surfaceless platform so that we don't need to bother bringing up weston or X11. The surface size is kept low to reduce runtime, but this comes at the cost of many rendering tests skipping due to too-small render targets (as we see the impact of Mesa on the shared runner pool, we can reevaluate this and what set of CTS tests we want to run). We split the job up across 4 runners (each at 4 llvmpipe threads), so that the job can load-balance across our shared runners and finish sooner (since dEQP is very single-thread-performance bound). Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-06-29 07:35:32 +08:00
gitlab-ci: Run piglit tests with llvmpipe One job for the quick_gl profile, one for the glslparser & quick_shader profiles (doing these together takes hardly any more time than quick_shader alone). v2: * Don't break lava tests v3: * Remove piglit test artifacts paths: * Exclude some quick_shader tests again: - Test whose result flips between pass/fail/skip - *@vs_in tests, as not the same one of these gets picked every time v4: * Do not list passing tests in .gitlab-ci/piglit/*.txt (Eric Anholt) * Include the test number summary in .gitlab-ci/piglit/*.txt * Completely disable generating any vs_in tests in the piglit build. * Remove some more unneded files from the piglit build tree. * Exclude quick_gl arb_gpu_shader5 tests; they were all skipped anyway, as llvmpipe doesn't support this extension yet, but occasionally they would spuriously fail instead. v5: * Set LD_LIBRARY_PATH, so we actually test the Mesa build from the pipeline... * Verify that wflinfo reports the expected Mesa version * Pass -noreset to Xvfb v6: * Don't use autoscale runners, run piglit with -j4 (Eric Anholt) Reviewed-by: Eric Anholt <eric@anholt.net>
2019-10-22 23:16:52 +08:00
.piglit-test:
extends: .test
artifacts:
reports:
junit: results/results.xml
variables:
LIBGL_ALWAYS_SOFTWARE: 1
PIGLIT_NO_WINDOW: 1
script:
- artifacts/piglit/run.sh
piglit-quick_gl:
extends: .piglit-test
variables:
LP_NUM_THREADS: 0
PIGLIT_OPTIONS: >
-x arb_gpu_shader5
-x glx-multithread-clearbuffer
-x glx-multithread-shader-compile
-x max-texture-size
-x maxsize
PIGLIT_PROFILES: quick_gl
piglit-glslparser+quick_shader:
extends: .piglit-test
variables:
LP_NUM_THREADS: 1
PIGLIT_OPTIONS: >
-x spec@arb_arrays_of_arrays@execution@ubo
-x spec@arb_gpu_shader_int64@execution$$
-x spec@arb_separate_shader_objects@execution
-x spec@arb_separate_shader_objects@linker
-x spec@arb_shader_storage_buffer_object@execution
-x spec@glsl-1.50@execution@built-in-functions
PIGLIT_PROFILES: "glslparser quick_shader"
PIGLIT_RESULTS: "glslparser+quick_shader"
.deqp-test:
extends: .test
variables:
DEQP_SKIPS: deqp-default-skips.txt
script:
- ./artifacts/deqp-runner.sh
gitlab-ci: Run the GLES2 CTS on llvmpipe. This is the start of doing CTS tests on merges to Mesa master. We use the surfaceless platform so that we don't need to bother bringing up weston or X11. The surface size is kept low to reduce runtime, but this comes at the cost of many rendering tests skipping due to too-small render targets (as we see the impact of Mesa on the shared runner pool, we can reevaluate this and what set of CTS tests we want to run). We split the job up across 4 runners (each at 4 llvmpipe threads), so that the job can load-balance across our shared runners and finish sooner (since dEQP is very single-thread-performance bound). Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-06-29 07:35:32 +08:00
test-llvmpipe-gles2:
variables:
DEQP_VER: gles2
ci: Use cts_runner for our dEQP runs. This runner is a little project by Bas, written in C++, that spawns threads that then loop grabbing chunks of the (randomly shuffled but consistently so) test list and hand it to a dEQP instance. As the remaining list gets shorter, so do the chunks, so hopefully the threads all complete effectively at once. It also handles restarting after crashes automatically. I've extended the runner a bit to do what I was doing in the bash scripts before, like the skip list and expected failures handling. This project should also be a good baseline for extending to handle retesting of intermittent failures. By switching to it, we can have the swrast tests just take up one job slot on the shared runners and keep their allotment of CPUs busy, instead of taking up job slots with single-threaded dEQP jobs. It will also let us (eventually, once I reprovision) switch the freedreno runners over to threading within the job instead of running concurrent jobs, so that memory scribbles in one pipeline don't affect unrelated pipelines, and I can experiment with their parallelism (particularly on a306 where we are frequently backed up) without trashing other people's jobs. What we lose in this process is per-test output in the log (not a big loss, I think, since we summarize fails at the end and reducing log length keeps chrome from choking on our logs so badly). We also drop the renderer sanity checking, since it's not saving qpa files for us to go poke through. Given that all the drivers involved have fail lists, if we got the wrong renderer somehow, we'd get a job failure anyway. v2: Rebase on droppong of the autoscale cluster and the arm64 build/test split. Use a script to deduplicate the cts-runner build. v3: Rebase on the amd64 build/test container split. Acked-by: Daniel Stone <daniels@collabora.com> (v1) Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> (v2)
2019-11-05 02:54:41 +08:00
DEQP_PARALLEL: 4
# Don't use threads inside llvmpipe, we've already got all 4 cores
# busy with DEQP_PARALLEL.
LP_NUM_THREADS: 0
gitlab-ci: Run the GLES2 CTS on llvmpipe. This is the start of doing CTS tests on merges to Mesa master. We use the surfaceless platform so that we don't need to bother bringing up weston or X11. The surface size is kept low to reduce runtime, but this comes at the cost of many rendering tests skipping due to too-small render targets (as we see the impact of Mesa on the shared runner pool, we can reevaluate this and what set of CTS tests we want to run). We split the job up across 4 runners (each at 4 llvmpipe threads), so that the job can load-balance across our shared runners and finish sooner (since dEQP is very single-thread-performance bound). Reviewed-by: Eric Engestrom <eric.engestrom@intel.com>
2019-06-29 07:35:32 +08:00
DEQP_EXPECTED_FAILS: deqp-llvmpipe-fails.txt
LIBGL_ALWAYS_SOFTWARE: "true"
extends: .deqp-test
gitlab-ci: Enable the GLES2/3 CTS on softpipe. The GLES2 CTS takes about 8 minutes of total runtime (at parallel 4 is ~2 minutes in the test stage if runners are free), while GLES3 takes about 25. Since the GLES3 run is pretty expensive, just do a cheap touch test of 1 out of every 10 tests in the test list on MRs, until we can get the runtime down. v2: Drop the full run for now until we can bring runtime down or bring up a dedicated mesa runner. Reviewed-by: Eric Engestrom <eric@engestrom.ch> (v1) Reviewed-By: Gert Wollny <gert.wollny@collabora.com> (v1)
2019-08-10 01:32:40 +08:00
test-softpipe-gles2:
gitlab-ci: Simplify some job definitions by extending more similar jobs v2: * Preserve setting NIR_VALIDATE=0 for all arm64_* jobs * Preserve setting DEQP_SKIPS=deqp-default-skips.txt for arm64_a306_gles2 jobs Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> # v1 Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-12 00:55:43 +08:00
extends: test-llvmpipe-gles2
gitlab-ci: Enable the GLES2/3 CTS on softpipe. The GLES2 CTS takes about 8 minutes of total runtime (at parallel 4 is ~2 minutes in the test stage if runners are free), while GLES3 takes about 25. Since the GLES3 run is pretty expensive, just do a cheap touch test of 1 out of every 10 tests in the test list on MRs, until we can get the runtime down. v2: Drop the full run for now until we can bring runtime down or bring up a dedicated mesa runner. Reviewed-by: Eric Engestrom <eric@engestrom.ch> (v1) Reviewed-By: Gert Wollny <gert.wollny@collabora.com> (v1)
2019-08-10 01:32:40 +08:00
variables:
DEQP_EXPECTED_FAILS: deqp-softpipe-fails.txt
ci: Use cts_runner for our dEQP runs. This runner is a little project by Bas, written in C++, that spawns threads that then loop grabbing chunks of the (randomly shuffled but consistently so) test list and hand it to a dEQP instance. As the remaining list gets shorter, so do the chunks, so hopefully the threads all complete effectively at once. It also handles restarting after crashes automatically. I've extended the runner a bit to do what I was doing in the bash scripts before, like the skip list and expected failures handling. This project should also be a good baseline for extending to handle retesting of intermittent failures. By switching to it, we can have the swrast tests just take up one job slot on the shared runners and keep their allotment of CPUs busy, instead of taking up job slots with single-threaded dEQP jobs. It will also let us (eventually, once I reprovision) switch the freedreno runners over to threading within the job instead of running concurrent jobs, so that memory scribbles in one pipeline don't affect unrelated pipelines, and I can experiment with their parallelism (particularly on a306 where we are frequently backed up) without trashing other people's jobs. What we lose in this process is per-test output in the log (not a big loss, I think, since we summarize fails at the end and reducing log length keeps chrome from choking on our logs so badly). We also drop the renderer sanity checking, since it's not saving qpa files for us to go poke through. Given that all the drivers involved have fail lists, if we got the wrong renderer somehow, we'd get a job failure anyway. v2: Rebase on droppong of the autoscale cluster and the arm64 build/test split. Use a script to deduplicate the cts-runner build. v3: Rebase on the amd64 build/test container split. Acked-by: Daniel Stone <daniels@collabora.com> (v1) Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> (v2)
2019-11-05 02:54:41 +08:00
DEQP_SKIPS: deqp-softpipe-skips.txt
gitlab-ci: Enable the GLES2/3 CTS on softpipe. The GLES2 CTS takes about 8 minutes of total runtime (at parallel 4 is ~2 minutes in the test stage if runners are free), while GLES3 takes about 25. Since the GLES3 run is pretty expensive, just do a cheap touch test of 1 out of every 10 tests in the test list on MRs, until we can get the runtime down. v2: Drop the full run for now until we can bring runtime down or bring up a dedicated mesa runner. Reviewed-by: Eric Engestrom <eric@engestrom.ch> (v1) Reviewed-By: Gert Wollny <gert.wollny@collabora.com> (v1)
2019-08-10 01:32:40 +08:00
GALLIUM_DRIVER: "softpipe"
ci: Enable all of GLES3/3.1 testing for softpipe. Now that we're not using so many job slots, it's easy to get these jobs run in a reasonable amount of time (gles3 took 10 minutes for 4 cores, and gles31 was 15 minutes for 4 cores). Acked-by: Michel Dänzer <mdaenzer@redhat.com>
2019-11-06 02:31:29 +08:00
test-softpipe-gles3:
parallel: 2
gitlab-ci: Enable the GLES2/3 CTS on softpipe. The GLES2 CTS takes about 8 minutes of total runtime (at parallel 4 is ~2 minutes in the test stage if runners are free), while GLES3 takes about 25. Since the GLES3 run is pretty expensive, just do a cheap touch test of 1 out of every 10 tests in the test list on MRs, until we can get the runtime down. v2: Drop the full run for now until we can bring runtime down or bring up a dedicated mesa runner. Reviewed-by: Eric Engestrom <eric@engestrom.ch> (v1) Reviewed-By: Gert Wollny <gert.wollny@collabora.com> (v1)
2019-08-10 01:32:40 +08:00
variables:
DEQP_VER: gles3
ci: Enable all of GLES3/3.1 testing for softpipe. Now that we're not using so many job slots, it's easy to get these jobs run in a reasonable amount of time (gles3 took 10 minutes for 4 cores, and gles31 was 15 minutes for 4 cores). Acked-by: Michel Dänzer <mdaenzer@redhat.com>
2019-11-06 02:31:29 +08:00
extends: test-softpipe-gles2
test-softpipe-gles31:
parallel: 4
variables:
DEQP_VER: gles31
extends: test-softpipe-gles2
freedreno: Introduce gitlab-based CI. Since freedreno's kernel and GPU reset seem to be totally solid, we don't need to have the complexity of the LAVA setup that panfrost has. Instead, we can register some boards as shared gitlab runners and have the jobs run out of a docker container just like we do for llvmpipe. Just make sure that the DRI device node is passed through to the containers in the gitlab config ('devices = ["/dev/dri"]' under runners.docker). If a runner fails (networking dies, kernel panic, etc.) it'll take out one build but the rest can keep going since gitlab-runner is what pulls jobs. Since the runner pulls jobs, it also means that they can live behind firewalls instead of needing some public address to be accessed by gitlab.fd.o. For now, enable it just on db410c (A307) and cheza (A630) as those are the hardware that I have plenty of. A307 is only testing GLES2 since running all of GLES3 takes too long for the number of boards I've brought up. Acked-by: Rob Clark <robdclark@chromium.org> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2019-06-29 07:35:32 +08:00
gitlab-ci: Simplify some job definitions by extending more similar jobs v2: * Preserve setting NIR_VALIDATE=0 for all arm64_* jobs * Preserve setting DEQP_SKIPS=deqp-default-skips.txt for arm64_a306_gles2 jobs Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> # v1 Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-12 00:55:43 +08:00
arm64_a630_gles2:
freedreno: Introduce gitlab-based CI. Since freedreno's kernel and GPU reset seem to be totally solid, we don't need to have the complexity of the LAVA setup that panfrost has. Instead, we can register some boards as shared gitlab runners and have the jobs run out of a docker container just like we do for llvmpipe. Just make sure that the DRI device node is passed through to the containers in the gitlab config ('devices = ["/dev/dri"]' under runners.docker). If a runner fails (networking dies, kernel panic, etc.) it'll take out one build but the rest can keep going since gitlab-runner is what pulls jobs. Since the runner pulls jobs, it also means that they can live behind firewalls instead of needing some public address to be accessed by gitlab.fd.o. For now, enable it just on db410c (A307) and cheza (A630) as those are the hardware that I have plenty of. A307 is only testing GLES2 since running all of GLES3 takes too long for the number of boards I've brought up. Acked-by: Rob Clark <robdclark@chromium.org> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2019-06-29 07:35:32 +08:00
extends: .deqp-test
gitlab-ci: Use separate arm64 build/test docker images The image used for test jobs is only about 1/6 as big as before, which may help avoid some issues with some of the test boards. Inspired by https://gitlab.freedesktop.org/mesa/mesa/issues/2046 . v2: * Leave LIBDRM_VERSION at 2.4.99 (Daniel Stone) * Delete more build artifacts from dEQP tree (Daniel Stone) v3: * Set LD_LIBRARY_PATH for ldd Acked-by: Daniel Stone <daniels@collabora.com> # v2 Reviewed-by: Eric Anholt <eric@anholt.net> # Except for the ldd line
2019-11-04 16:54:09 +08:00
image: $DEBIAN_ARM64_TEST_IMAGE
freedreno: Introduce gitlab-based CI. Since freedreno's kernel and GPU reset seem to be totally solid, we don't need to have the complexity of the LAVA setup that panfrost has. Instead, we can register some boards as shared gitlab runners and have the jobs run out of a docker container just like we do for llvmpipe. Just make sure that the DRI device node is passed through to the containers in the gitlab config ('devices = ["/dev/dri"]' under runners.docker). If a runner fails (networking dies, kernel panic, etc.) it'll take out one build but the rest can keep going since gitlab-runner is what pulls jobs. Since the runner pulls jobs, it also means that they can live behind firewalls instead of needing some public address to be accessed by gitlab.fd.o. For now, enable it just on db410c (A307) and cheza (A630) as those are the hardware that I have plenty of. A307 is only testing GLES2 since running all of GLES3 takes too long for the number of boards I've brought up. Acked-by: Rob Clark <robdclark@chromium.org> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2019-06-29 07:35:32 +08:00
variables:
DEQP_VER: gles2
DEQP_EXPECTED_FAILS: deqp-freedreno-a630-fails.txt
DEQP_SKIPS: deqp-freedreno-a630-skips.txt
NIR_VALIDATE: 0
tags:
- mesa-cheza
dependencies:
- meson-arm64
gitlab-ci: Add test-container:arm64 to needs: for arm64 test jobs Without this, it was theoretically possible for the jobs to run before the docker image was ready. v2: * Use - list syntax instead of [] (Eric Engestrom) Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-18 22:28:41 +08:00
needs:
- meson-arm64
gitlab-ci: Use separate arm64 build/test docker images The image used for test jobs is only about 1/6 as big as before, which may help avoid some issues with some of the test boards. Inspired by https://gitlab.freedesktop.org/mesa/mesa/issues/2046 . v2: * Leave LIBDRM_VERSION at 2.4.99 (Daniel Stone) * Delete more build artifacts from dEQP tree (Daniel Stone) v3: * Set LD_LIBRARY_PATH for ldd Acked-by: Daniel Stone <daniels@collabora.com> # v2 Reviewed-by: Eric Anholt <eric@anholt.net> # Except for the ldd line
2019-11-04 16:54:09 +08:00
- debian-10-test:arm64
freedreno: Introduce gitlab-based CI. Since freedreno's kernel and GPU reset seem to be totally solid, we don't need to have the complexity of the LAVA setup that panfrost has. Instead, we can register some boards as shared gitlab runners and have the jobs run out of a docker container just like we do for llvmpipe. Just make sure that the DRI device node is passed through to the containers in the gitlab config ('devices = ["/dev/dri"]' under runners.docker). If a runner fails (networking dies, kernel panic, etc.) it'll take out one build but the rest can keep going since gitlab-runner is what pulls jobs. Since the runner pulls jobs, it also means that they can live behind firewalls instead of needing some public address to be accessed by gitlab.fd.o. For now, enable it just on db410c (A307) and cheza (A630) as those are the hardware that I have plenty of. A307 is only testing GLES2 since running all of GLES3 takes too long for the number of boards I've brought up. Acked-by: Rob Clark <robdclark@chromium.org> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2019-06-29 07:35:32 +08:00
gitlab-ci: Simplify some job definitions by extending more similar jobs v2: * Preserve setting NIR_VALIDATE=0 for all arm64_* jobs * Preserve setting DEQP_SKIPS=deqp-default-skips.txt for arm64_a306_gles2 jobs Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> # v1 Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-12 00:55:43 +08:00
arm64_a630_gles31:
extends: arm64_a630_gles2
parallel: 4
freedreno: Introduce gitlab-based CI. Since freedreno's kernel and GPU reset seem to be totally solid, we don't need to have the complexity of the LAVA setup that panfrost has. Instead, we can register some boards as shared gitlab runners and have the jobs run out of a docker container just like we do for llvmpipe. Just make sure that the DRI device node is passed through to the containers in the gitlab config ('devices = ["/dev/dri"]' under runners.docker). If a runner fails (networking dies, kernel panic, etc.) it'll take out one build but the rest can keep going since gitlab-runner is what pulls jobs. Since the runner pulls jobs, it also means that they can live behind firewalls instead of needing some public address to be accessed by gitlab.fd.o. For now, enable it just on db410c (A307) and cheza (A630) as those are the hardware that I have plenty of. A307 is only testing GLES2 since running all of GLES3 takes too long for the number of boards I've brought up. Acked-by: Rob Clark <robdclark@chromium.org> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2019-06-29 07:35:32 +08:00
variables:
gitlab-ci: Simplify some job definitions by extending more similar jobs v2: * Preserve setting NIR_VALIDATE=0 for all arm64_* jobs * Preserve setting DEQP_SKIPS=deqp-default-skips.txt for arm64_a306_gles2 jobs Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> # v1 Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-12 00:55:43 +08:00
DEQP_VER: gles31
freedreno: Introduce gitlab-based CI. Since freedreno's kernel and GPU reset seem to be totally solid, we don't need to have the complexity of the LAVA setup that panfrost has. Instead, we can register some boards as shared gitlab runners and have the jobs run out of a docker container just like we do for llvmpipe. Just make sure that the DRI device node is passed through to the containers in the gitlab config ('devices = ["/dev/dri"]' under runners.docker). If a runner fails (networking dies, kernel panic, etc.) it'll take out one build but the rest can keep going since gitlab-runner is what pulls jobs. Since the runner pulls jobs, it also means that they can live behind firewalls instead of needing some public address to be accessed by gitlab.fd.o. For now, enable it just on db410c (A307) and cheza (A630) as those are the hardware that I have plenty of. A307 is only testing GLES2 since running all of GLES3 takes too long for the number of boards I've brought up. Acked-by: Rob Clark <robdclark@chromium.org> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2019-06-29 07:35:32 +08:00
arm64_a630_gles3:
parallel: 6
gitlab-ci: Simplify some job definitions by extending more similar jobs v2: * Preserve setting NIR_VALIDATE=0 for all arm64_* jobs * Preserve setting DEQP_SKIPS=deqp-default-skips.txt for arm64_a306_gles2 jobs Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> # v1 Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-12 00:55:43 +08:00
extends: arm64_a630_gles2
freedreno: Introduce gitlab-based CI. Since freedreno's kernel and GPU reset seem to be totally solid, we don't need to have the complexity of the LAVA setup that panfrost has. Instead, we can register some boards as shared gitlab runners and have the jobs run out of a docker container just like we do for llvmpipe. Just make sure that the DRI device node is passed through to the containers in the gitlab config ('devices = ["/dev/dri"]' under runners.docker). If a runner fails (networking dies, kernel panic, etc.) it'll take out one build but the rest can keep going since gitlab-runner is what pulls jobs. Since the runner pulls jobs, it also means that they can live behind firewalls instead of needing some public address to be accessed by gitlab.fd.o. For now, enable it just on db410c (A307) and cheza (A630) as those are the hardware that I have plenty of. A307 is only testing GLES2 since running all of GLES3 takes too long for the number of boards I've brought up. Acked-by: Rob Clark <robdclark@chromium.org> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2019-06-29 07:35:32 +08:00
variables:
DEQP_VER: gles3
gitlab-ci: Simplify some job definitions by extending more similar jobs v2: * Preserve setting NIR_VALIDATE=0 for all arm64_* jobs * Preserve setting DEQP_SKIPS=deqp-default-skips.txt for arm64_a306_gles2 jobs Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> # v1 Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-12 00:55:43 +08:00
arm64_a306_gles2:
freedreno: Introduce gitlab-based CI. Since freedreno's kernel and GPU reset seem to be totally solid, we don't need to have the complexity of the LAVA setup that panfrost has. Instead, we can register some boards as shared gitlab runners and have the jobs run out of a docker container just like we do for llvmpipe. Just make sure that the DRI device node is passed through to the containers in the gitlab config ('devices = ["/dev/dri"]' under runners.docker). If a runner fails (networking dies, kernel panic, etc.) it'll take out one build but the rest can keep going since gitlab-runner is what pulls jobs. Since the runner pulls jobs, it also means that they can live behind firewalls instead of needing some public address to be accessed by gitlab.fd.o. For now, enable it just on db410c (A307) and cheza (A630) as those are the hardware that I have plenty of. A307 is only testing GLES2 since running all of GLES3 takes too long for the number of boards I've brought up. Acked-by: Rob Clark <robdclark@chromium.org> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2019-06-29 07:35:32 +08:00
parallel: 4
gitlab-ci: Simplify some job definitions by extending more similar jobs v2: * Preserve setting NIR_VALIDATE=0 for all arm64_* jobs * Preserve setting DEQP_SKIPS=deqp-default-skips.txt for arm64_a306_gles2 jobs Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> # v1 Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-12 00:55:43 +08:00
extends: arm64_a630_gles2
freedreno: Introduce gitlab-based CI. Since freedreno's kernel and GPU reset seem to be totally solid, we don't need to have the complexity of the LAVA setup that panfrost has. Instead, we can register some boards as shared gitlab runners and have the jobs run out of a docker container just like we do for llvmpipe. Just make sure that the DRI device node is passed through to the containers in the gitlab config ('devices = ["/dev/dri"]' under runners.docker). If a runner fails (networking dies, kernel panic, etc.) it'll take out one build but the rest can keep going since gitlab-runner is what pulls jobs. Since the runner pulls jobs, it also means that they can live behind firewalls instead of needing some public address to be accessed by gitlab.fd.o. For now, enable it just on db410c (A307) and cheza (A630) as those are the hardware that I have plenty of. A307 is only testing GLES2 since running all of GLES3 takes too long for the number of boards I've brought up. Acked-by: Rob Clark <robdclark@chromium.org> Acked-by: Kenneth Graunke <kenneth@whitecape.org>
2019-06-29 07:35:32 +08:00
variables:
gitlab-ci: Simplify some job definitions by extending more similar jobs v2: * Preserve setting NIR_VALIDATE=0 for all arm64_* jobs * Preserve setting DEQP_SKIPS=deqp-default-skips.txt for arm64_a306_gles2 jobs Reviewed-by: Eric Engestrom <eric.engestrom@intel.com> # v1 Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-12 00:55:43 +08:00
DEQP_EXPECTED_FAILS: deqp-freedreno-a307-fails.txt
DEQP_SKIPS: deqp-default-skips.txt
tags:
- db410c
Reference in New Issue Copy Permalink