| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'm working on moving the db410c CI from docker to LAVA, which means we
get to boot a custom kernel. To do that, we need to enable ARCH_QCOM in
the kernel, save the dtb around, and include abootimg in our container so
that we can generate combined kernel/dtb/ramdisk images for fastboot.
LAVA's fastboot support is unable to pack the overlay into an abootimg
image, just a cpio rootfs. We could flash the cpio rootfs after overlay
addition, but that takes 2 minutes to do, and causes wear on the devices.
Instead, we'll bring up the network at boot and use wget to fetch the
overlay. We'll want network support anyway, so that we can transfer the
failure xmls back to the gitlab job's artifacts at some point.
Since the msm GPU and realtek network firmware increase our payload by
3MB, add in firmware compression so that it doesn't waste as much RAM on
devices not using it.
Reviewed-by: Tomeu Vizoso <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3928>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3928>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The LLVM libraries were a significant fraction of the entire payload
(55M/250M uncompressed) into the initramfs of the test boards, but
LLVM is only used for the draw module used in select/feedback (which
isn't even tested in CI on ARM yet).
Assume that llvmpipe draw is safe enough for ARM given the coverage on
x86, and disable LLVM for these jobs.
Reviewed-by: Tomeu Vizoso <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3928>
|
|
|
|
|
|
|
|
|
|
|
|
| |
radv needs libllvm which increases our ramdisk size
significantly. Since this driver is only build tested,
we can split it out into a separate job.
Signed-off-by: Rohan Garg <[email protected]>
Reviewed-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Reviewed-by: Tomeu Vizoso <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3928>
|
|
|
|
|
|
|
|
|
|
| |
There's two fixes that help with stability when running dEQP on Kevin
Chromebooks.
Signed-off-by: Tomeu Vizoso <[email protected]>
Reviewed-by: Alyssa Rosenzweig <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3876>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3876>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LAVA finds a '#' early in boot and races to emit its shell commands.
Apparently for the current boards those serial commands end up getting
buffered such that things work out, but for db410c and db820c, the buffer
is lost and LAVA gets stuck waiting for the prompt. By setting a prompt,
we can delay our commands until we're actually supposed to emit them (and
suppress a complaint from the lava dispatcher that we're using a risky
prompt!)
Reviewed-by: Tomeu Vizoso <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3883>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce automated testing of Mesa by replaying traces with Renderdoc
or Apitrace.
For now only LLVMPipe is tested, but other drivers can be tested if
there's runners with the necessary hardware.
Signed-off-by: Alexandros Frantzis <[email protected]>
Signed-off-by: Tomeu Vizoso <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2935>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2935>
|
|
|
|
|
|
|
|
|
| |
v3: remove version in a few places (Michel)
Reviewed-by: Michel Dänzer <[email protected]>
Reviewed-by: Adam Jackson <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3805>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3805>
|
|
|
|
|
|
|
| |
This reverts commit 18657c0c0a9074d3dfc0763b396929bcf34f71b4
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3804>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3804>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The fdo-packet-* runners keep hitting the (already quite long) timeouts
for some of the tests, taking many times as long for them as the
gstreamer runners.
The fdo-gitlab-gce-runner3 runner would work as well, but it doesn't
have any tags we could use.
Acked-by: Daniel Stone <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3760>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3760>
|
|
|
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3758>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3758>
|
|
|
|
|
| |
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3742>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3742>
|
|
|
|
|
|
|
|
|
|
| |
This brings in the surfaceless fixes so we don't need to check out the
whole repo to cherry pick any more (which was bothering me as I debugged
things late in the painfully slow ARM container build process).
Reviewed-by: Michel Dänzer <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3662>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3662>
|
|
|
|
|
|
|
|
|
| |
This requires cross-building libdrm for ppc64el.
Reviewed-by: Adam Jackson <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3643>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3643>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using LLVM 8 for ppc64el and 7 for s390x (which hits some coroutine
related issues with LLVM 8).
There are some test failures we need to ignore for now. Also, the
timeout needs to be bumped from the default 30s for some tests, because
they can take longer under emulation.
Reviewed-by: Adam Jackson <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3643>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Among other things, this increases robustness when copying a docker
image from the main Mesa project to a forked project, avoiding spurious
image rebuilds from scratch.
Also drop the comment about .gitlab-ci/lava-gitlab-ci.yml, it doesn't
include the templates anymore.
Reviewed-by: Adam Jackson <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3643>
|
|
|
|
|
|
|
|
|
| |
All fixes we were carrying in our branch have been merged already.
Signed-off-by: Tomeu Vizoso <[email protected]>
Reviewed-by: Alyssa Rosenzweig <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3692>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3692>
|
|
|
|
|
|
|
| |
This reverts commit f38851d84c583b1c62ea95edbc42eb5e2ad14fa8
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3687>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3687>
|
|
|
|
|
|
| |
Signed-off-by: Eric Engestrom <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3677>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3677>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I find warnings to be very disruptive to my workflow (using emacs's "go to
next error" feature), and I periodically have to go clean up other
people's drivers to get back to finding my own warnings in the noise. I
know I'm not the only one doing something like this.
We don't want to enable -Werror by default in builds, since it means that
end users will have builds spuriously fail based on what compiler version
and opt flags they have compared to what the devs are using. However, it
is quite easy to have CI ensure that we at least don't introduce warnings
on the compiler version that it uses.
For now I've just enabled it on meson-i386 to cover a bunch of Mesa core
and get us started on ratcheting up warnings-cleanliness in the tree,
without me having to fix up all the drivers at once.
Reviewed-by: Daniel Stone <[email protected]>
Reviewed-by: Kristian H. Kristensen <[email protected]>
Reviewed-by: Alyssa Rosenzweig <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3539>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3539>
|
|
|
|
|
|
|
|
|
|
|
|
| |
I thought multiple ifs would all need to match, but looks like only the
last one (or either one?) does.
This should prevent a manual pipeline from getting created after merging
changes which can't affect the pipeline.
Reviewed-by: Eric Engestrom <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3474>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3474>
|
|
|
|
|
|
|
| |
It doesn't need anything from the Git repository.
Reviewed-by: Eric Engestrom <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3474>
|
|
|
|
|
|
|
|
|
| |
This test's result is unpredictable, so it may occasionally pass when we
expect it to fail, thus causing the CI pipeline to fail.
Reviewed-by: Eric Anholt <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3498>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3498>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
They were causing trouble with Marge Bot: The project settings require
that the pipeline succeeds before a merge request (MR) can be merged,
otherwise Marge doesn't wait for the pipeline to succeed before merging
an MR assigned to her. But Marge can't start manual jobs, so she would
always time out waiting for pipelines with manual jobs.
To avoid this, use these rules:
* Run the pipeline by default for MRs and main project branches changing
any files affecting it.
* For other MRs, run a single dummy job which always succeeds.
* Don't run any jobs for main project branch changes (e.g. from an MR
having been merged) not affecting the pipeline.
* Allow jobs to be started manually on branches of forked projects, as
before.
Acked-by: Pierre-Eric Pelloux-Prayer <[email protected]>
Acked-by: Daniel Stone <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3361>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3361>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Acked-by: Alyssa Rosenzweig <[email protected]>
Reviewed-by: Daniel Stone <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295>
|
|
|
|
|
|
|
|
| |
They're not available for Debian buster yet, so we have to use upstream
snapshot packages again.
In contrast to earlier, we now store the LLVM APT repository key in Git
instead of re-downloading it every time.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Take one step towards sharing code between the LAVA and non-LAVA jobs,
with the goals of reducing maintenance burden and use of computational
resources.
The env var DEQP_NO_SAVE_RESULTS allows us to skip the procesing of the
XML result files, which can take a long time and is not useful in the
LAVA case as we are not uploading artifacts anywhere at the moment.
Signed-off-by: Tomeu Vizoso <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
Add LP_DEBUG=tgsi_ir (tgsi already taken) to fallback to TGSI paths.
Disable NIR_VALIDATE in CI (Michel/Eric acked)
Reviewed-by: Roland Scheidegger <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2303>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2303>
|
|
|
|
|
|
|
| |
This is used to validate if the driver emits correct LLVM IR.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Bas Nieuwenhuizen <[email protected]>
|
|
|
|
|
|
|
| |
Now that we're running these with process isolation enabled, their
results will hopefully be stable.
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Only Polaris10 is tested at the moment, and I disabled a TON of
tests to keep a CTS run within 5 minutes because my local runner
is a bit slow. A full CTS run takes more than 1h, which means it
will hit the timeout.
RADV CI can only be triggered manually on personal branches to
avoid breaking the world because one runner is definitely not
enough. This will allow us to test it until it's stable enough
to be enabled by default.
Signed-off-by: Samuel Pitoiset <[email protected]>
Acked-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
|
| |
This requires to bump LLVM to 8 because it's the minimum supported
version by RADV.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use new rules: instead of only:
For container stage jobs:
* In the main Mesa project, run them by default.
* In merge requests, run them by default if any files affecting pipeline
results are changed.
* In all other cases (in particular branches in personal projects),
don't run them by default but allow triggering them manually.
build & test stage jobs are left at the default (when: on_success), so
they will run automatically once all their dependencies are satisified.
(Using the same rules as above would require these jobs to be manually
triggered as well, which is only possible once all dependency jobs have
passed) Please be considerate of CI runner resources and cancel unneeded
jobs on personal branches with no corresponding merge requests (this can
be done before the jobs start running).
In summary: No more special branch names. Unnecessary job runs are
avoided by default, but jobs which don't run by default can be triggered
manually.
v2:
* Split out LAVA changes to separate commit
* Clarify commit log a little, in particular WRT build/test stage jobs
Reviewed-by: Samuel Pitoiset <[email protected]> # v1
Reviewed-by: Pierre-Eric Pelloux-Prayer <[email protected]> # v1
Reviewed-by: Tomeu Vizoso <[email protected]> # v1
Acked-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the runner has a HW device that would be supported, even without
/dev/dri forwarded into the container, it will be enumerated and the tests
on llvmpipe fail with (for example):
libEGL warning: Not allowed to force software rendering when API explicitly selects a hardware device.
libEGL warning: MESA-LOADER: failed to open i965 (search paths /builds/anholt/mesa/install/lib/dri)
Given that we can't necessarily control the DRI devices present on the
runners (particularly for developers bringing their own runners to reduce
the demands on fd.o's shared resources), just skip these tests in CI.
Reviewed-by: Michel Dänzer <[email protected]>
|
|
|
|
|
|
|
|
| |
Commit also updates the Piglit quick_gl.txt, list modifications happened
due to following Piglit commits: c248bf201,c acff58ca, 5603e2e60.
Signed-off-by: Tapani Pälli <[email protected]>
Reviewed-by: Timothy Arceri <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
| |
And only use --process-isolation false for the quick_gl tests.
This will hopefully avoid variance in the test results that we've been
seeing lately. But even if it doesn't, it should at least help narrow
down the cause of the variance.
Tested-by: Vasily Khoruzhick <[email protected]>
Acked-by: Pierre-Eric Pelloux-Prayer <[email protected]>
|
|
|
|
|
|
| |
They don't seem to be hugely useful, and seem to be bogging down gitlab.
Signed-off-by: Rob Clark <[email protected]>
|
|
|
|
|
|
| |
Fixes skopeo copy failures.
Reviewed-by: Pierre-Eric Pelloux-Prayer <[email protected]>
|
|
|
|
|
|
|
| |
This will make it easier to look at details of failed / skipped tests.
Acked-by: Daniel Stone <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
| |
It was basically useless in this form, and processing the JUnit data in
the GitLab backend was pretty expensive.
Acked-by: Daniel Stone <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
| |
Signed-off-by: Rob Clark <[email protected]>
Acked-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
| |
To pick up updated cts_runner and netcat for the flake reporting.
Signed-off-by: Rob Clark <[email protected]>
Acked-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If there are a small number of fails, re-run to determine if they are
flakes, and optionally (if `$FLAKES_CHANNEL` configured) report the
flakes.
This way flakes don't interfere with developers working on other
drivers, but get logged so that the developers working on the flaking
driver can monitor the situation.
Signed-off-by: Rob Clark <[email protected]>
Acked-by: Eric Engestrom <[email protected]>
|
|
|
|
|
|
|
|
|
|
| |
It seems overkill to me to build scons 7x for every pipeline.
Scons is now build with the oldest llvm version in scons-old-llvm
and with the newest llvm version in scons.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Michel Dänzer <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I set the runners to concurrency=1, so they serve only one gitlab-ci job
at at time. Swap over to using the parallel runner now to keep the
runners busy, more efficiently than spawning many docker containers and
downloading artifacts multiple times, and producing easier-to-understand
results for browsing on the web.
This bumps the a306 runners to 4x parallel instead of 2x like before, but
cheza gles3 drops from 6 to 4. Current rough timings of the jobs (if no
container download):
db410c-gles2: 5:00
a630-gles2: 1:30
a630-gles3: 6:00
a630-gles31: 5:30
a630-gles3 is a bit longer than I like, but it should come back down once
I can sort out the NIR algebraic rewinding.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use hardcoded /cache/mesa/ccache for the cache, so it will be shared by
all jobs of all Mesa projects running on the same runner host. This
should increase the hit rate and decrease the worst case storage used.
Further benefits of directly using a host-mapped directory:
* Saves up to ~1 minute per job for restoring and saving the cache
contents via the GitLab CI cache mechanism
* Cache contents generated by failed jobs are no longer lost
* Jobs running in parallel on the same runner host can get hits from
each other
Also enable compression, so the default maximum cache size of 5G might
be sufficient.
v2:
* Move CCACHE_DIR variable to the .build-linux template
Suggested-by: Eric Anholt <[email protected]>
Reviewed-by: Eric Anholt <[email protected]> # v1
|
|
|
|
|
|
|
| |
All things are already part of meson-main.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Michel Dänzer <[email protected]>
|