mirrors/mesa
0
0
Fork 0
mirror of https://gitlab.freedesktop.org/mesa/mesa.git synced 2024-11-30 21:54:16 +08:00
Code Issues Packages Projects Releases Wiki Activity
2aa507f87a
mesa/.gitlab-ci/lava-gitlab-ci.yml

188 lines
5.0 KiB
YAML
Raw Normal View History

gitlab-ci: More stable URL for kernel and ramdisk artifacts, for LAVA Place the kernel and ramdisk into a place in the file server so the URL will only change when the contents also change. Also put the Mesa build into a separate tarball so the ramdisk's contents don't change every build. With proper caching in place, all devices in the same farm need only to download the mesa tarball once, saving time. As we switch to MinIO for making kernels and rootfs available to LAVA devices, we can stop using Docker to distribute them. Instead, build when needed in separate jobs that push directly to MinIO, from where LAVA devices can download them. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Daniel Stone <daniels@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5515>
2020-04-01 19:07:46 +08:00
variables:
DISTRIBUTION_TAG: "2020-07-06"
.kernel+rootfs:
stage: container-2
gitlab-ci: Remove left-behind rules: It's something that was added to ease development, but that was supposed to be removed before merging. It also causes problems when arm-related jobs aren't enabled, as arm_build is needed by these jobs but in that case isn't there. Also extend from .ci-run-policy. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5802>
2020-07-08 15:57:44 +08:00
extends:
- .ci-run-policy
gitlab-ci: More stable URL for kernel and ramdisk artifacts, for LAVA Place the kernel and ramdisk into a place in the file server so the URL will only change when the contents also change. Also put the Mesa build into a separate tarball so the ramdisk's contents don't change every build. With proper caching in place, all devices in the same farm need only to download the mesa tarball once, saving time. As we switch to MinIO for making kernels and rootfs available to LAVA devices, we can stop using Docker to distribute them. Instead, build when needed in separate jobs that push directly to MinIO, from where LAVA devices can download them. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Daniel Stone <daniels@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5515>
2020-04-01 19:07:46 +08:00
variables:
GIT_STRATEGY: fetch
script:
- DEBIAN_ARCH=${DEBIAN_ARCH} .gitlab-ci/container/lava_arm.sh
kernel+rootfs_arm64:
extends:
- .use-arm_build
- .kernel+rootfs
tags:
- aarch64
variables:
DEBIAN_ARCH: "arm64"
kernel+rootfs_armhf:
extends:
- kernel+rootfs_arm64
variables:
DEBIAN_ARCH: "armhf"
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
.lava-test:
gitlab-ci: Move LAVA-related files into top-level ci dir In preparation for testing drivers other than Panfrost in LAVA labs. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-18 22:43:30 +08:00
extends:
gitlab-ci: Use the common run policy for LAVA jobs as well again Having different policies could have some weird results, e.g. changes only touching documentation (where the intention is not to run the pipeline by default) would still create a pipeline with the LAVA jobs running by default. Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Eric Engestrom <eric.engestrom@intel.com>
2019-12-06 16:39:40 +08:00
- .ci-run-policy
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
variables:
GIT_STRATEGY: none # testing doesn't build anything from source
gitlab-ci: Run GLES3 tests in dEQP on Panfrost We are able to run only 1/5th of the tests in around the same time that dEQP-GLES2 takes, so do that for now while more DUTs are installed. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3876>
2019-12-18 23:11:33 +08:00
ENV_VARS: "DEQP_PARALLEL=6"
DEQP_VERSION: gles2
gitlab-ci: Don't rebuild kernels and rootfs if they have been already built in mainline Use the ones from mainline if possible to save cycles rebuilding the same files. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5822>
2020-07-09 22:14:14 +08:00
ARTIFACTS_PREFIX: "https://minio-packet.freedesktop.org/mesa-lava/"
gitlab-ci: More stable URL for kernel and ramdisk artifacts, for LAVA Place the kernel and ramdisk into a place in the file server so the URL will only change when the contents also change. Also put the Mesa build into a separate tarball so the ramdisk's contents don't change every build. With proper caching in place, all devices in the same farm need only to download the mesa tarball once, saving time. As we switch to MinIO for making kernels and rootfs available to LAVA devices, we can stop using Docker to distribute them. Instead, build when needed in separate jobs that push directly to MinIO, from where LAVA devices can download them. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Daniel Stone <daniels@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5515>
2020-04-01 19:07:46 +08:00
MESA_URL: "https://minio-packet.freedesktop.org/artifacts/${CI_PROJECT_PATH}/${CI_PIPELINE_ID}/mesa-${ARCH}.tar.gz"
panfrost/ci: Initial commit These files implement running almost all of deqp-gles2 on Chomebooks of the rk3399-gru-kevin type in Collabora's LAVA lab. The approach follows what is currently being used for virglrenderer, but scheduling the actual test jobs via LAVA. We start by building a container in Docker that contains a suitable rootfs and kernel for the DUT, deqp and all dependencies for building Mesa itself. The Mesa is built and the rootfs, deqp and Mesa are combined in a cpio ramdisk. A LAVA job is generated, submitted to LAVA and the results are processed by simply comparing them to the expectations that are stored in git. Any code that changes the expectations (hopefully tests are fixed) needs to also update the expectations file. The next step is adding support for other devices, possibly in other LAVA labs. In order to use this, the repository has to be configured to run the gitlab-ci.yaml file from the panfrost/ci dir, and a LAVA token needs to be setup. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-04-30 00:33:22 +08:00
script:
gitlab-ci: Don't rebuild kernels and rootfs if they have been already built in mainline Use the ones from mainline if possible to save cycles rebuilding the same files. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5822>
2020-07-09 22:14:14 +08:00
# Try to use the kernel and rootfs built in mainline first, to save cycles
- >
if wget -q --method=HEAD "${ARTIFACTS_PREFIX}/mesa/mesa/${DISTRIBUTION_TAG}/${ARCH}/done"; then
ARTIFACTS_URL="${ARTIFACTS_PREFIX}/mesa/mesa/${DISTRIBUTION_TAG}/${ARCH}"
else
ARTIFACTS_URL="${ARTIFACTS_PREFIX}/${CI_PROJECT_PATH}/${DISTRIBUTION_TAG}/${ARCH}"
fi
gitlab-ci: Consolidate container and build stages for LAVA Use the normal build job to also prepare the artifacts for LAVA jobs. For that, the build container needs to also build the test suites, kernel, ramdisk, etc. Then the build job will place the just-built Mesa in the ramdisk and the test job can generate a LAVA job and point to those artifacts. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295>
2019-12-17 18:50:14 +08:00
- >
artifacts/generate_lava.py \
--template artifacts/lava-deqp.yml.jinja2 \
gitlab-ci/lava: add pipeline information in the lava job name In order to have more informations in the LAVA jobs list, add the current pipeline URL and commit ref name in the LAVA job name. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2337> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2337>
2019-10-15 21:22:07 +08:00
--pipeline-info "$CI_PIPELINE_URL on $CI_COMMIT_REF_NAME ${CI_NODE_INDEX}/${CI_NODE_TOTAL}" \
gitlab-ci: More stable URL for kernel and ramdisk artifacts, for LAVA Place the kernel and ramdisk into a place in the file server so the URL will only change when the contents also change. Also put the Mesa build into a separate tarball so the ramdisk's contents don't change every build. With proper caching in place, all devices in the same farm need only to download the mesa tarball once, saving time. As we switch to MinIO for making kernels and rootfs available to LAVA devices, we can stop using Docker to distribute them. Instead, build when needed in separate jobs that push directly to MinIO, from where LAVA devices can download them. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Daniel Stone <daniels@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5515>
2020-04-01 19:07:46 +08:00
--base-artifacts-url ${ARTIFACTS_URL} \
--mesa-url ${MESA_URL} \
gitlab-ci: Consolidate container and build stages for LAVA Use the normal build job to also prepare the artifacts for LAVA jobs. For that, the build container needs to also build the test suites, kernel, ramdisk, etc. Then the build job will place the just-built Mesa in the ramdisk and the test job can generate a LAVA job and point to those artifacts. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295>
2019-12-17 18:50:14 +08:00
--device-type ${DEVICE_TYPE} \
--env-vars "${ENV_VARS}" \
gitlab-ci: Run GLES3 tests in dEQP on Panfrost We are able to run only 1/5th of the tests in around the same time that dEQP-GLES2 takes, so do that for now while more DUTs are installed. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3876>
2019-12-18 23:11:33 +08:00
--deqp-version ${DEQP_VERSION} \
gitlab-ci: Consolidate container and build stages for LAVA Use the normal build job to also prepare the artifacts for LAVA jobs. For that, the build container needs to also build the test suites, kernel, ramdisk, etc. Then the build job will place the just-built Mesa in the ramdisk and the test job can generate a LAVA job and point to those artifacts. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295>
2019-12-17 18:50:14 +08:00
--kernel-image-name ${KERNEL_IMAGE_NAME} \
--kernel-image-type "${KERNEL_IMAGE_TYPE}" \
--gpu-version ${GPU_VERSION} \
--boot-method ${BOOT_METHOD} \
ci: lava: pass CI_NODE_INDEX and CI_NODE_TOTAL to lava jobs deqp-runner.sh uses it to determine whether we split job across multiple devices and if we do what's the node index. With this change we now can set 'parallel: N' in job description if we want to split the job. Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3163>
2020-01-17 11:37:32 +08:00
--lava-tags "${LAVA_TAGS}" \
--ci-node-index "${CI_NODE_INDEX}" \
--ci-node-total "${CI_NODE_TOTAL}"
gitlab-ci: Serve files for LAVA via separate service Currently, we store the kernel and ramdisk for each LAVA job in the artifacts of the job that built them. Because artifacts are stored in GCE and LAVA labs aren't, this causes a lot of egress with is expensive. To avoid this, have runners download most of the data via the (cached) container images once, and for each job upload the kernel and ramdisk to a server outside GCE. Right now we only have Collabora's runner with a local web server, so jobs that go to Baylibre's lab have been disabled. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Eric Anholt <eric@anholt.net> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4295>
2020-03-24 19:58:43 +08:00
- lava_job_id=`lavacli jobs submit lava-deqp.yml` || lavacli jobs submit lava-deqp.yml
panfrost/ci: Use Volt-based runner for dEQP tests It's able to run tests in parallel, fully utilizing the HW and shortening considerable the time it takes. Needed to disable tests in RK3288 for now because Volt doesn't support armhf yet, though this should be fixed soon. Tests are now run with --deqp-gl-config-name=rgba8888d24s8ms0, so we are hitting a few more failures in tests that previously were being skipped. The time to run the tests decreases from around 8 minutes to 1:45 minutes, allowing for extending coverage without increasing CI times too much. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-08-15 16:41:21 +08:00
- echo $lava_job_id
gitlab-ci: Consolidate container and build stages for LAVA Use the normal build job to also prepare the artifacts for LAVA jobs. For that, the build container needs to also build the test suites, kernel, ramdisk, etc. Then the build job will place the just-built Mesa in the ramdisk and the test job can generate a LAVA job and point to those artifacts. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295>
2019-12-17 18:50:14 +08:00
- rm -rf artifacts/*
- cp lava-deqp.yml artifacts/.
ci: Remove a useless filtering of the lava logs. We don't print every case any more, so no need to filter them out. This makes it so the output form "lavacli jobs logs" gets line-buffered into "tee" and you can actually see what happened when the job is stuck but before it times out. Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3883> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3883>
2020-02-21 02:15:43 +08:00
- lavacli jobs logs $lava_job_id | tee artifacts/lava-deqp-$lava_job_id.log
panfrost/ci: Initial commit These files implement running almost all of deqp-gles2 on Chomebooks of the rk3399-gru-kevin type in Collabora's LAVA lab. The approach follows what is currently being used for virglrenderer, but scheduling the actual test jobs via LAVA. We start by building a container in Docker that contains a suitable rootfs and kernel for the DUT, deqp and all dependencies for building Mesa itself. The Mesa is built and the rootfs, deqp and Mesa are combined in a cpio ramdisk. A LAVA job is generated, submitted to LAVA and the results are processed by simply comparing them to the expectations that are stored in git. Any code that changes the expectations (hopefully tests are fixed) needs to also update the expectations file. The next step is adding support for other devices, possibly in other LAVA labs. In order to use this, the repository has to be configured to run the gitlab-ci.yaml file from the panfrost/ci dir, and a LAVA token needs to be setup. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-04-30 00:33:22 +08:00
- lavacli jobs show $lava_job_id
panfrost/ci: Use Volt-based runner for dEQP tests It's able to run tests in parallel, fully utilizing the HW and shortening considerable the time it takes. Needed to disable tests in RK3288 for now because Volt doesn't support armhf yet, though this should be fixed soon. Tests are now run with --deqp-gl-config-name=rgba8888d24s8ms0, so we are hitting a few more failures in tests that previously were being skipped. The time to run the tests decreases from around 8 minutes to 1:45 minutes, allowing for extending coverage without increasing CI times too much. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-08-15 16:41:21 +08:00
- result=`lavacli results $lava_job_id 0_deqp deqp | head -1`
- echo $result
gitlab-ci: Move LAVA-related files into top-level ci dir In preparation for testing drivers other than Panfrost in LAVA labs. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-18 22:43:30 +08:00
- '[[ "$result" == "pass" ]]'
panfrost/ci: Initial commit These files implement running almost all of deqp-gles2 on Chomebooks of the rk3399-gru-kevin type in Collabora's LAVA lab. The approach follows what is currently being used for virglrenderer, but scheduling the actual test jobs via LAVA. We start by building a container in Docker that contains a suitable rootfs and kernel for the DUT, deqp and all dependencies for building Mesa itself. The Mesa is built and the rootfs, deqp and Mesa are combined in a cpio ramdisk. A LAVA job is generated, submitted to LAVA and the results are processed by simply comparing them to the expectations that are stored in git. Any code that changes the expectations (hopefully tests are fixed) needs to also update the expectations file. The next step is adding support for other devices, possibly in other LAVA labs. In order to use this, the repository has to be configured to run the gitlab-ci.yaml file from the panfrost/ci dir, and a LAVA token needs to be setup. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-04-30 00:33:22 +08:00
artifacts:
gitlab-ci: Always name artifacts archive after the job producing it This will help determine which artifacts generate how much traffic. v2: * Add "mesa_" prefix to make it obvious which project the artifacts are from. Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Reviewed-by: Eric Anholt <eric@anholt.net> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4085> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4085>
2020-03-06 19:35:17 +08:00
name: "mesa_${CI_JOB_NAME}"
panfrost/ci: Initial commit These files implement running almost all of deqp-gles2 on Chomebooks of the rk3399-gru-kevin type in Collabora's LAVA lab. The approach follows what is currently being used for virglrenderer, but scheduling the actual test jobs via LAVA. We start by building a container in Docker that contains a suitable rootfs and kernel for the DUT, deqp and all dependencies for building Mesa itself. The Mesa is built and the rootfs, deqp and Mesa are combined in a cpio ramdisk. A LAVA job is generated, submitted to LAVA and the results are processed by simply comparing them to the expectations that are stored in git. Any code that changes the expectations (hopefully tests are fixed) needs to also update the expectations file. The next step is adding support for other devices, possibly in other LAVA labs. In order to use this, the repository has to be configured to run the gitlab-ci.yaml file from the panfrost/ci dir, and a LAVA token needs to be setup. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-04-30 00:33:22 +08:00
when: always
paths:
gitlab-ci: Consolidate container and build stages for LAVA Use the normal build job to also prepare the artifacts for LAVA jobs. For that, the build container needs to also build the test suites, kernel, ramdisk, etc. Then the build job will place the just-built Mesa in the ramdisk and the test job can generate a LAVA job and point to those artifacts. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295>
2019-12-17 18:50:14 +08:00
- artifacts/
panfrost: ci: Add support for running the tests on RK3288 Build artifacts for armhf and schedule them on a Veyron Chromebook with RK3288. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-03 23:48:48 +08:00
gitlab-ci/lava: Test Lima driver with dEQP Run dEQP on boards with Mali 400 and 450 in Baylibre's lab. There's lots of skipped tests because of crashes and undetermined behavior. May be a good idea to run the tests with valgrind and fix any issues found. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
2019-10-06 23:49:56 +08:00
.lava-test:armhf:
gitlab-ci: Organize images using new REPO_SUFFIX templates feature Two benefits: Most docker image related environment variables can now be defined in the jobs where they're used instead of globally. The DEBIAN_TAG values are propagated to other jobs via YAML anchors. Images on https://gitlab.freedesktop.org/mesa/mesa/container_registry are now organized in separate repositories with a suffix matching the name of the job which makes sure the image is there. Acked-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Engestrom <eric@engestrom.ch>
2019-11-12 01:13:28 +08:00
variables:
gitlab-ci: Consolidate container and build stages for LAVA Use the normal build job to also prepare the artifacts for LAVA jobs. For that, the build container needs to also build the test suites, kernel, ramdisk, etc. Then the build job will place the just-built Mesa in the ramdisk and the test job can generate a LAVA job and point to those artifacts. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295>
2019-12-17 18:50:14 +08:00
ARCH: armhf
KERNEL_IMAGE_NAME: zImage
KERNEL_IMAGE_TYPE: "type:\ zimage"
BOOT_METHOD: u-boot
extends:
- .lava-test
- .use-arm_build
needs:
gitlab-ci: More stable URL for kernel and ramdisk artifacts, for LAVA Place the kernel and ramdisk into a place in the file server so the URL will only change when the contents also change. Also put the Mesa build into a separate tarball so the ramdisk's contents don't change every build. With proper caching in place, all devices in the same farm need only to download the mesa tarball once, saving time. As we switch to MinIO for making kernels and rootfs available to LAVA devices, we can stop using Docker to distribute them. Instead, build when needed in separate jobs that push directly to MinIO, from where LAVA devices can download them. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Daniel Stone <daniels@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5515>
2020-04-01 19:07:46 +08:00
- kernel+rootfs_armhf
gitlab-ci: Consolidate container and build stages for LAVA Use the normal build job to also prepare the artifacts for LAVA jobs. For that, the build container needs to also build the test suites, kernel, ramdisk, etc. Then the build job will place the just-built Mesa in the ramdisk and the test job can generate a LAVA job and point to those artifacts. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295>
2019-12-17 18:50:14 +08:00
- meson-armhf
panfrost: ci: Add support for running the tests on RK3288 Build artifacts for armhf and schedule them on a Veyron Chromebook with RK3288. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-03 23:48:48 +08:00
gitlab-ci/lava: Test Lima driver with dEQP Run dEQP on boards with Mali 400 and 450 in Baylibre's lab. There's lots of skipped tests because of crashes and undetermined behavior. May be a good idea to run the tests with valgrind and fix any issues found. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
2019-10-06 23:49:56 +08:00
.lava-test:arm64:
gitlab-ci: Organize images using new REPO_SUFFIX templates feature Two benefits: Most docker image related environment variables can now be defined in the jobs where they're used instead of globally. The DEBIAN_TAG values are propagated to other jobs via YAML anchors. Images on https://gitlab.freedesktop.org/mesa/mesa/container_registry are now organized in separate repositories with a suffix matching the name of the job which makes sure the image is there. Acked-by: Eric Anholt <eric@anholt.net> Reviewed-by: Eric Engestrom <eric@engestrom.ch>
2019-11-12 01:13:28 +08:00
variables:
gitlab-ci: Consolidate container and build stages for LAVA Use the normal build job to also prepare the artifacts for LAVA jobs. For that, the build container needs to also build the test suites, kernel, ramdisk, etc. Then the build job will place the just-built Mesa in the ramdisk and the test job can generate a LAVA job and point to those artifacts. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295>
2019-12-17 18:50:14 +08:00
ARCH: arm64
KERNEL_IMAGE_NAME: Image
KERNEL_IMAGE_TYPE: "type:\ image"
BOOT_METHOD: u-boot
extends:
- .lava-test
- .use-arm_build
needs:
gitlab-ci: More stable URL for kernel and ramdisk artifacts, for LAVA Place the kernel and ramdisk into a place in the file server so the URL will only change when the contents also change. Also put the Mesa build into a separate tarball so the ramdisk's contents don't change every build. With proper caching in place, all devices in the same farm need only to download the mesa tarball once, saving time. As we switch to MinIO for making kernels and rootfs available to LAVA devices, we can stop using Docker to distribute them. Instead, build when needed in separate jobs that push directly to MinIO, from where LAVA devices can download them. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Daniel Stone <daniels@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5515>
2020-04-01 19:07:46 +08:00
- kernel+rootfs_arm64
gitlab-ci: Consolidate container and build stages for LAVA Use the normal build job to also prepare the artifacts for LAVA jobs. For that, the build container needs to also build the test suites, kernel, ramdisk, etc. Then the build job will place the just-built Mesa in the ramdisk and the test job can generate a LAVA job and point to those artifacts. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295>
2019-12-17 18:50:14 +08:00
- meson-arm64
gitlab-ci/lava: Test Lima driver with dEQP Run dEQP on boards with Mali 400 and 450 in Baylibre's lab. There's lots of skipped tests because of crashes and undetermined behavior. May be a good idea to run the tests with valgrind and fix any issues found. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
2019-10-06 23:49:56 +08:00
Revert "CI: Disable Panfrost T720/T760" Switches have been rewired, VLANs have been reconfigured, network elements with non-functional remote management have been removed from racks and thrown on desks in anger. This reverts commit ae6e1aee7d1bd49ae494b8a25ca33d092a3a145a. Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5301>
2020-06-03 02:59:00 +08:00
panfrost-t720-gles2:arm64:
gitlab-ci: rules:changes to test on tested drivers changes For now tests only use these drivers: * llvmpipe * softpipe * freedreno * lima * etnaviv * panfrost So using rules:changes gitlab feature to run the tests when the changes made are potentially affecting these drivers. A few notes: * the following code: .piglit-test: extends: - .test-gl - .llvmpipe-rules makes gitlab replace .test-gl "rules:changes" values by the one from ".llvmpipe-rules". * rules:changes always matches for non-MR new branches so jobs will always be created (and they'll be run if their dependencies are run). For pushes to existing branches the files changed by the push are used to match the rules:changes path. * the same gitlab feature could be used for some build jobs Acked-by: Eric Engestrom <eric@engestrom.ch> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2569> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2569>
2019-10-31 03:39:08 +08:00
extends:
- .lava-test:arm64
- .panfrost-rules
gitlab-ci: Test Panfrost on T720 GPUs Now that the Mali T720 GPU is supoprted at the same level as the T760, test it on PINE64 H64 boards. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-10-25 19:04:34 +08:00
variables:
DEVICE_TYPE: sun50i-h6-pine-h64
gitlab-ci: Consolidate container and build stages for LAVA Use the normal build job to also prepare the artifacts for LAVA jobs. For that, the build container needs to also build the test suites, kernel, ramdisk, etc. Then the build job will place the just-built Mesa in the ramdisk and the test job can generate a LAVA job and point to those artifacts. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295>
2019-12-17 18:50:14 +08:00
GPU_VERSION: panfrost-t720
ci: Add sanity checking that dEQP gets the expected GL_RENDERER. It's easy to get something wrong in the driver build or container or something that results in falling back to swrast, and then your only clue was runtime and how your failure cases suspiciously match a swrast driver's. Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4621>
2020-04-18 03:39:32 +08:00
ENV_VARS: "PAN_MESA_DEBUG=gles3 DEQP_PARALLEL=6 DEQP_EXPECTED_RENDERER=T720"
gitlab-ci: Test Panfrost on T720 GPUs Now that the Mali T720 GPU is supoprted at the same level as the T760, test it on PINE64 H64 boards. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-10-25 19:04:34 +08:00
tags:
gitlab-ci: Serve files for LAVA via separate service Currently, we store the kernel and ramdisk for each LAVA job in the artifacts of the job that built them. Because artifacts are stored in GCE and LAVA labs aren't, this causes a lot of egress with is expensive. To avoid this, have runners download most of the data via the (cached) container images once, and for each job upload the kernel and ramdisk to a server outside GCE. Right now we only have Collabora's runner with a local web server, so jobs that go to Baylibre's lab have been disabled. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Eric Anholt <eric@anholt.net> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4295>
2020-03-24 19:58:43 +08:00
- mesa-ci-aarch64-lava-collabora
gitlab-ci: Test Panfrost on T720 GPUs Now that the Mali T720 GPU is supoprted at the same level as the T760, test it on PINE64 H64 boards. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
2019-10-25 19:04:34 +08:00
Revert "CI: Disable Panfrost T720/T760" Switches have been rewired, VLANs have been reconfigured, network elements with non-functional remote management have been removed from racks and thrown on desks in anger. This reverts commit ae6e1aee7d1bd49ae494b8a25ca33d092a3a145a. Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5301>
2020-06-03 02:59:00 +08:00
panfrost-t760-gles2:armhf:
gitlab-ci: rules:changes to test on tested drivers changes For now tests only use these drivers: * llvmpipe * softpipe * freedreno * lima * etnaviv * panfrost So using rules:changes gitlab feature to run the tests when the changes made are potentially affecting these drivers. A few notes: * the following code: .piglit-test: extends: - .test-gl - .llvmpipe-rules makes gitlab replace .test-gl "rules:changes" values by the one from ".llvmpipe-rules". * rules:changes always matches for non-MR new branches so jobs will always be created (and they'll be run if their dependencies are run). For pushes to existing branches the files changed by the push are used to match the rules:changes path. * the same gitlab feature could be used for some build jobs Acked-by: Eric Engestrom <eric@engestrom.ch> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2569> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2569>
2019-10-31 03:39:08 +08:00
extends:
- .lava-test:armhf
- .panfrost-rules
gitlab-ci/lava: Test Lima driver with dEQP Run dEQP on boards with Mali 400 and 450 in Baylibre's lab. There's lots of skipped tests because of crashes and undetermined behavior. May be a good idea to run the tests with valgrind and fix any issues found. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
2019-10-06 23:49:56 +08:00
variables:
DEVICE_TYPE: rk3288-veyron-jaq
gitlab-ci: Consolidate container and build stages for LAVA Use the normal build job to also prepare the artifacts for LAVA jobs. For that, the build container needs to also build the test suites, kernel, ramdisk, etc. Then the build job will place the just-built Mesa in the ramdisk and the test job can generate a LAVA job and point to those artifacts. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295>
2019-12-17 18:50:14 +08:00
GPU_VERSION: panfrost-t760
BOOT_METHOD: depthcharge
KERNEL_IMAGE_TYPE: ""
ci: Add sanity checking that dEQP gets the expected GL_RENDERER. It's easy to get something wrong in the driver build or container or something that results in falling back to swrast, and then your only clue was runtime and how your failure cases suspiciously match a swrast driver's. Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4621>
2020-04-18 03:39:32 +08:00
ENV_VARS: "PAN_MESA_DEBUG=gles3 DEQP_PARALLEL=6 DEQP_EXPECTED_RENDERER=T760"
gitlab-ci/lava: Test Lima driver with dEQP Run dEQP on boards with Mali 400 and 450 in Baylibre's lab. There's lots of skipped tests because of crashes and undetermined behavior. May be a good idea to run the tests with valgrind and fix any issues found. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
2019-10-06 23:49:56 +08:00
tags:
gitlab-ci: Serve files for LAVA via separate service Currently, we store the kernel and ramdisk for each LAVA job in the artifacts of the job that built them. Because artifacts are stored in GCE and LAVA labs aren't, this causes a lot of egress with is expensive. To avoid this, have runners download most of the data via the (cached) container images once, and for each job upload the kernel and ramdisk to a server outside GCE. Right now we only have Collabora's runner with a local web server, so jobs that go to Baylibre's lab have been disabled. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Eric Anholt <eric@anholt.net> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4295>
2020-03-24 19:58:43 +08:00
- mesa-ci-aarch64-lava-collabora
gitlab-ci/lava: Test Lima driver with dEQP Run dEQP on boards with Mali 400 and 450 in Baylibre's lab. There's lots of skipped tests because of crashes and undetermined behavior. May be a good idea to run the tests with valgrind and fix any issues found. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
2019-10-06 23:49:56 +08:00
CI: Re-enable Panfrost T860 jobs The lab is back online. This reverts commit 34db50558d9a6dca89218f74c4418cdf0b0acbcb. Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5694>
2020-06-30 21:49:16 +08:00
panfrost-t860-gles2:arm64:
gitlab-ci: rules:changes to test on tested drivers changes For now tests only use these drivers: * llvmpipe * softpipe * freedreno * lima * etnaviv * panfrost So using rules:changes gitlab feature to run the tests when the changes made are potentially affecting these drivers. A few notes: * the following code: .piglit-test: extends: - .test-gl - .llvmpipe-rules makes gitlab replace .test-gl "rules:changes" values by the one from ".llvmpipe-rules". * rules:changes always matches for non-MR new branches so jobs will always be created (and they'll be run if their dependencies are run). For pushes to existing branches the files changed by the push are used to match the rules:changes path. * the same gitlab feature could be used for some build jobs Acked-by: Eric Engestrom <eric@engestrom.ch> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2569> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2569>
2019-10-31 03:39:08 +08:00
extends:
- .lava-test:arm64
- .panfrost-rules
gitlab-ci/lava: Test Lima driver with dEQP Run dEQP on boards with Mali 400 and 450 in Baylibre's lab. There's lots of skipped tests because of crashes and undetermined behavior. May be a good idea to run the tests with valgrind and fix any issues found. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
2019-10-06 23:49:56 +08:00
variables:
DEVICE_TYPE: rk3399-gru-kevin
gitlab-ci: Consolidate container and build stages for LAVA Use the normal build job to also prepare the artifacts for LAVA jobs. For that, the build container needs to also build the test suites, kernel, ramdisk, etc. Then the build job will place the just-built Mesa in the ramdisk and the test job can generate a LAVA job and point to those artifacts. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295>
2019-12-17 18:50:14 +08:00
GPU_VERSION: panfrost-t860
BOOT_METHOD: depthcharge
KERNEL_IMAGE_TYPE: ""
ci: Add sanity checking that dEQP gets the expected GL_RENDERER. It's easy to get something wrong in the driver build or container or something that results in falling back to swrast, and then your only clue was runtime and how your failure cases suspiciously match a swrast driver's. Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4621>
2020-04-18 03:39:32 +08:00
ENV_VARS: "PAN_MESA_DEBUG=gles3 DEQP_PARALLEL=6 DEQP_EXPECTED_RENDERER=T860"
gitlab-ci: Move LAVA-related files into top-level ci dir In preparation for testing drivers other than Panfrost in LAVA labs. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Eric Anholt <eric@anholt.net>
2019-09-18 22:43:30 +08:00
tags:
gitlab-ci: Serve files for LAVA via separate service Currently, we store the kernel and ramdisk for each LAVA job in the artifacts of the job that built them. Because artifacts are stored in GCE and LAVA labs aren't, this causes a lot of egress with is expensive. To avoid this, have runners download most of the data via the (cached) container images once, and for each job upload the kernel and ramdisk to a server outside GCE. Right now we only have Collabora's runner with a local web server, so jobs that go to Baylibre's lab have been disabled. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Eric Anholt <eric@anholt.net> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4295>
2020-03-24 19:58:43 +08:00
- mesa-ci-aarch64-lava-collabora
panfrost: ci: Add support for running the tests on RK3288 Build artifacts for armhf and schedule them on a Veyron Chromebook with RK3288. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
2019-05-03 23:48:48 +08:00
CI: Re-enable Panfrost T860 jobs The lab is back online. This reverts commit 34db50558d9a6dca89218f74c4418cdf0b0acbcb. Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5694>
2020-06-30 21:49:16 +08:00
panfrost-t860-gles3:arm64:
gitlab-ci: Run all of GLES3 tests for Panfrost We have enough capacity now and Panfrost should be very near to GLES3 compliance. v2: Update fails list (Alyssa) Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5932>
2020-07-16 16:24:35 +08:00
parallel: 2
gitlab-ci: rules:changes to test on tested drivers changes For now tests only use these drivers: * llvmpipe * softpipe * freedreno * lima * etnaviv * panfrost So using rules:changes gitlab feature to run the tests when the changes made are potentially affecting these drivers. A few notes: * the following code: .piglit-test: extends: - .test-gl - .llvmpipe-rules makes gitlab replace .test-gl "rules:changes" values by the one from ".llvmpipe-rules". * rules:changes always matches for non-MR new branches so jobs will always be created (and they'll be run if their dependencies are run). For pushes to existing branches the files changed by the push are used to match the rules:changes path. * the same gitlab feature could be used for some build jobs Acked-by: Eric Engestrom <eric@engestrom.ch> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2569> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2569>
2019-10-31 03:39:08 +08:00
extends:
- .lava-test:arm64
- .panfrost-rules
gitlab-ci: Run GLES3 tests in dEQP on Panfrost We are able to run only 1/5th of the tests in around the same time that dEQP-GLES2 takes, so do that for now while more DUTs are installed. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3876>
2019-12-18 23:11:33 +08:00
variables:
DEVICE_TYPE: rk3399-gru-kevin
GPU_VERSION: panfrost-t860
BOOT_METHOD: depthcharge
KERNEL_IMAGE_TYPE: ""
DEQP_VERSION: gles3
ci: Add sanity checking that dEQP gets the expected GL_RENDERER. It's easy to get something wrong in the driver build or container or something that results in falling back to swrast, and then your only clue was runtime and how your failure cases suspiciously match a swrast driver's. Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4621>
2020-04-18 03:39:32 +08:00
ENV_VARS: "PAN_MESA_DEBUG=gles3 DEQP_PARALLEL=6 DEQP_EXPECTED_RENDERER=T860"
gitlab-ci: Run GLES3 tests in dEQP on Panfrost We are able to run only 1/5th of the tests in around the same time that dEQP-GLES2 takes, so do that for now while more DUTs are installed. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3876>
2019-12-18 23:11:33 +08:00
tags:
gitlab-ci: Serve files for LAVA via separate service Currently, we store the kernel and ramdisk for each LAVA job in the artifacts of the job that built them. Because artifacts are stored in GCE and LAVA labs aren't, this causes a lot of egress with is expensive. To avoid this, have runners download most of the data via the (cached) container images once, and for each job upload the kernel and ramdisk to a server outside GCE. Right now we only have Collabora's runner with a local web server, so jobs that go to Baylibre's lab have been disabled. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Eric Anholt <eric@anholt.net> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4295>
2020-03-24 19:58:43 +08:00
- mesa-ci-aarch64-lava-collabora
gitlab-ci: Run GLES3 tests in dEQP on Panfrost We are able to run only 1/5th of the tests in around the same time that dEQP-GLES2 takes, so do that for now while more DUTs are installed. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Eric Anholt <eric@anholt.net> Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3876>
2019-12-18 23:11:33 +08:00
CI: Disable Panfrost Mali-T820, Lima Mali-400 and Lima Mali-450 jobs The runners appear to be unhealthy. Disable for now so people can merge patches for other drivers in the meantime. Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5619>
2020-06-24 10:23:32 +08:00
.panfrost-t820-gles2:arm64:
gitlab-ci: rules:changes to test on tested drivers changes For now tests only use these drivers: * llvmpipe * softpipe * freedreno * lima * etnaviv * panfrost So using rules:changes gitlab feature to run the tests when the changes made are potentially affecting these drivers. A few notes: * the following code: .piglit-test: extends: - .test-gl - .llvmpipe-rules makes gitlab replace .test-gl "rules:changes" values by the one from ".llvmpipe-rules". * rules:changes always matches for non-MR new branches so jobs will always be created (and they'll be run if their dependencies are run). For pushes to existing branches the files changed by the push are used to match the rules:changes path. * the same gitlab feature could be used for some build jobs Acked-by: Eric Engestrom <eric@engestrom.ch> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2569> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2569>
2019-10-31 03:39:08 +08:00
extends:
- .lava-test:arm64
- .panfrost-rules
Add support for T820 CI Jobs Tomeu: - Small rebase fixups Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
2019-09-20 21:43:19 +08:00
variables:
DEVICE_TYPE: meson-gxm-khadas-vim2
gitlab-ci: Consolidate container and build stages for LAVA Use the normal build job to also prepare the artifacts for LAVA jobs. For that, the build container needs to also build the test suites, kernel, ramdisk, etc. Then the build job will place the just-built Mesa in the ramdisk and the test job can generate a LAVA job and point to those artifacts. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295>
2019-12-17 18:50:14 +08:00
GPU_VERSION: panfrost-t820
LAVA_TAGS: panfrost
ci: Add sanity checking that dEQP gets the expected GL_RENDERER. It's easy to get something wrong in the driver build or container or something that results in falling back to swrast, and then your only clue was runtime and how your failure cases suspiciously match a swrast driver's. Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4621>
2020-04-18 03:39:32 +08:00
ENV_VARS: "PAN_MESA_DEBUG=gles3 DEQP_PARALLEL=6 DEQP_EXPECTED_RENDERER=T820"
Add support for T820 CI Jobs Tomeu: - Small rebase fixups Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
2019-09-20 21:43:19 +08:00
tags:
gitlab-ci: re-enable mali400/450 and t820 jobs The FILES_HOST_NAME and FILES_HOST_URL are in the baylibre's runner environment to make it more flexible. Also use the new aarch64 mesa-ci-aarch64-lava-baylibre runner with embedded nginx server to serve the LAVA artifacts. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4295> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4295>
2020-03-26 00:06:18 +08:00
- mesa-ci-aarch64-lava-baylibre
Add support for T820 CI Jobs Tomeu: - Small rebase fixups Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
2019-09-20 21:43:19 +08:00
CI: Disable Panfrost Mali-T820, Lima Mali-400 and Lima Mali-450 jobs The runners appear to be unhealthy. Disable for now so people can merge patches for other drivers in the meantime. Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5619>
2020-06-24 10:23:32 +08:00
.lima-mali400-test:armhf:
ci: Re-enable CI for lima on mali450 Amend fails and skips lists basing on lists from Andreas Baierl, shard mali400 job across two devices since it takes close to 10min and rename jobs to lima-mali400-test and lima-mali450-test. Also don't set MESA_GLES_VERSION_OVERRIDE=3.0 for lima since we don't support GLES 3.0 and lower DEQP_PARALLEL to 3 for jobs on H3. Keep mali400 jobs disabled atm since they take too much time to complete and we also get some unexplicable failures in dEQP-GLES2.functional.default_vertex_attrib.* Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3163> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3163>
2019-12-19 14:15:11 +08:00
parallel: 2
gitlab-ci: rules:changes to test on tested drivers changes For now tests only use these drivers: * llvmpipe * softpipe * freedreno * lima * etnaviv * panfrost So using rules:changes gitlab feature to run the tests when the changes made are potentially affecting these drivers. A few notes: * the following code: .piglit-test: extends: - .test-gl - .llvmpipe-rules makes gitlab replace .test-gl "rules:changes" values by the one from ".llvmpipe-rules". * rules:changes always matches for non-MR new branches so jobs will always be created (and they'll be run if their dependencies are run). For pushes to existing branches the files changed by the push are used to match the rules:changes path. * the same gitlab feature could be used for some build jobs Acked-by: Eric Engestrom <eric@engestrom.ch> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2569> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2569>
2019-10-31 03:39:08 +08:00
extends:
- .lava-test:armhf
- .lima-rules
gitlab-ci/lava: Test Lima driver with dEQP Run dEQP on boards with Mali 400 and 450 in Baylibre's lab. There's lots of skipped tests because of crashes and undetermined behavior. May be a good idea to run the tests with valgrind and fix any issues found. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
2019-10-06 23:49:56 +08:00
variables:
DEVICE_TYPE: sun8i-h3-libretech-all-h3-cc
gitlab-ci: Consolidate container and build stages for LAVA Use the normal build job to also prepare the artifacts for LAVA jobs. For that, the build container needs to also build the test suites, kernel, ramdisk, etc. Then the build job will place the just-built Mesa in the ramdisk and the test job can generate a LAVA job and point to those artifacts. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295>
2019-12-17 18:50:14 +08:00
GPU_VERSION: lima
ci: Add sanity checking that dEQP gets the expected GL_RENDERER. It's easy to get something wrong in the driver build or container or something that results in falling back to swrast, and then your only clue was runtime and how your failure cases suspiciously match a swrast driver's. Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4621>
2020-04-18 03:39:32 +08:00
ENV_VARS: "DEQP_PARALLEL=3 DEQP_EXPECTED_RENDERER=Mali400"
gitlab-ci/lava: Test Lima driver with dEQP Run dEQP on boards with Mali 400 and 450 in Baylibre's lab. There's lots of skipped tests because of crashes and undetermined behavior. May be a good idea to run the tests with valgrind and fix any issues found. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
2019-10-06 23:49:56 +08:00
tags:
gitlab-ci: re-enable mali400/450 and t820 jobs The FILES_HOST_NAME and FILES_HOST_URL are in the baylibre's runner environment to make it more flexible. Also use the new aarch64 mesa-ci-aarch64-lava-baylibre runner with embedded nginx server to serve the LAVA artifacts. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4295> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4295>
2020-03-26 00:06:18 +08:00
- mesa-ci-aarch64-lava-baylibre
gitlab-ci/lava: Test Lima driver with dEQP Run dEQP on boards with Mali 400 and 450 in Baylibre's lab. There's lots of skipped tests because of crashes and undetermined behavior. May be a good idea to run the tests with valgrind and fix any issues found. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
2019-10-06 23:49:56 +08:00
CI: Disable Panfrost Mali-T820, Lima Mali-400 and Lima Mali-450 jobs The runners appear to be unhealthy. Disable for now so people can merge patches for other drivers in the meantime. Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5619>
2020-06-24 10:23:32 +08:00
.lima-mali450-test:arm64:
gitlab-ci: rules:changes to test on tested drivers changes For now tests only use these drivers: * llvmpipe * softpipe * freedreno * lima * etnaviv * panfrost So using rules:changes gitlab feature to run the tests when the changes made are potentially affecting these drivers. A few notes: * the following code: .piglit-test: extends: - .test-gl - .llvmpipe-rules makes gitlab replace .test-gl "rules:changes" values by the one from ".llvmpipe-rules". * rules:changes always matches for non-MR new branches so jobs will always be created (and they'll be run if their dependencies are run). For pushes to existing branches the files changed by the push are used to match the rules:changes path. * the same gitlab feature could be used for some build jobs Acked-by: Eric Engestrom <eric@engestrom.ch> Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2569> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2569>
2019-10-31 03:39:08 +08:00
extends:
- .lava-test:arm64
- .lima-rules
gitlab-ci/lava: Test Lima driver with dEQP Run dEQP on boards with Mali 400 and 450 in Baylibre's lab. There's lots of skipped tests because of crashes and undetermined behavior. May be a good idea to run the tests with valgrind and fix any issues found. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
2019-10-06 23:49:56 +08:00
variables:
DEVICE_TYPE: meson-gxl-s905x-libretech-cc
gitlab-ci: Consolidate container and build stages for LAVA Use the normal build job to also prepare the artifacts for LAVA jobs. For that, the build container needs to also build the test suites, kernel, ramdisk, etc. Then the build job will place the just-built Mesa in the ramdisk and the test job can generate a LAVA job and point to those artifacts. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295>
2019-12-17 18:50:14 +08:00
GPU_VERSION: lima
ci: Add sanity checking that dEQP gets the expected GL_RENDERER. It's easy to get something wrong in the driver build or container or something that results in falling back to swrast, and then your only clue was runtime and how your failure cases suspiciously match a swrast driver's. Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4621>
2020-04-18 03:39:32 +08:00
ENV_VARS: "DEQP_PARALLEL=6 DEQP_EXPECTED_RENDERER=Mali450"
gitlab-ci/lava: Test Lima driver with dEQP Run dEQP on boards with Mali 400 and 450 in Baylibre's lab. There's lots of skipped tests because of crashes and undetermined behavior. May be a good idea to run the tests with valgrind and fix any issues found. Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by: Vasily Khoruzhick <anarsoul@gmail.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
2019-10-06 23:49:56 +08:00
tags:
gitlab-ci: re-enable mali400/450 and t820 jobs The FILES_HOST_NAME and FILES_HOST_URL are in the baylibre's runner environment to make it more flexible. Also use the new aarch64 mesa-ci-aarch64-lava-baylibre runner with embedded nginx server to serve the LAVA artifacts. Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4295> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4295>
2020-03-26 00:06:18 +08:00
- mesa-ci-aarch64-lava-baylibre
Reference in New Issue Copy Permalink