| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
| |
robclark found that we needed unique IDs when multiple runners were trying
to report flakes at the same time, but it turns out due to nick limits (16
chars on freenode) we were just getting all the runners appended with
"-142" (or whatever the prefix of the pipelines are these days). And, for
the new flake reporting from baremetal, all the runners ended up being
just "google-freedreno".
Reviewed-by: Rob Clark <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4896>
|
| |
|
|
|
|
|
|
|
| |
We were incorrectly taking the merge-request on non-MR pipelines (the
master build after merge) due to a missing '$'. And, for those pipelines,
it would be nice to note whether they're for master or a stable branch.
Reviewed-by: Rob Clark <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4896>
|
| |
|
|
|
|
|
|
|
|
| |
`wc -l $file` returns the number of lines and the filename.
Fixes: b8c66aeb934 ("ci: Clean up some excessive use of pipes in dEQP results processing.")
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Andres Gomez <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4829>
|
| |
|
|
|
|
|
|
|
|
| |
This lets us get coverage of corner cases of the driver that are tricky to
force a testcase to hit. We don't want to do a full run of the CTS with
each option because that's a lot of runner time, so stack a bunch of
fractional runs in one test job to amortize the test run setup overhead.
Reviewed-by: Tomeu Vizoso <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4621>
|
| |
|
|
|
|
|
|
| |
Given that we use set -x in the script, this actually makes the user
experience of viewing logs nicer.
Reviewed-by: Tomeu Vizoso <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4621>
|
| |
|
|
|
|
|
|
|
| |
I want to do multiple runs of some bits of the CTS in one test job to test
some driver options, but I want to be able to see the results from any of
them.
Reviewed-by: Tomeu Vizoso <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4621>
|
| |
|
|
|
|
|
|
|
|
| |
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 <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4621>
|
| |
|
|
|
|
|
|
| |
We always want to see status updates happening in the logs, otherwise it
can like maybe your machine hung until the run actually completes.
Reviewed-by: Tomeu Vizoso <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4621>
|
| |
|
|
|
|
| |
Signed-off-by: Tomeu Vizoso <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4659>
|
| |
|
|
|
|
|
|
|
| |
Add virglrenderer to the container and use the vtest transport to test
the Gallium driver. On the "host", llvmpipe is used.
Signed-off-by: Tomeu Vizoso <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4433>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's some files from the .gitlab-ci directory that are needed in the
test stage and that, because the Mesa repository isn't checked out in
that stage, need to be made available through other means.
Because those files are going to be needed in LAVA devices, place them
ino the tarball containing the built files so it's available to both
gitlab-ci runners and LAVA devices.
Before those files were passed in the artifacts of the Gitlab CI job,
but this commit places them into the built tarball so scripts later in
the pipeline don't need to account for this discrepancy.
Signed-off-by: Tomeu Vizoso <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4295>
|
| |
|
|
|
|
|
|
|
| |
if $DEQP_PARALLEL is not set, it will use the maximum number of
jobs instead of 1.
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Eric Anholt <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4179>
|
| |
|
|
|
|
|
| |
This is useful for sanity checking how the driver loads.
Lightly-reviewed-by: Kristian H. Kristensen <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4076>
|
| |
|
|
|
|
|
|
|
| |
We disabled presentation a while back because it's so expensive for gitlab
to parse it on the other side. We may have a use for it some day if
gitlab gets better, but for now let's not spend the time processing it.
Reviewed-by: Tomeu Vizoso <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3883>
|
| |
|
|
|
|
|
|
|
| |
When bringing up a new board or starting a new GLES version, we have a lot
of unexpected fails to document, so we need the full list in the log (not
just deqp-runner.sh's head -n 50) so we can populate the xfail list.
Reviewed-by: Tomeu Vizoso <[email protected]>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3883>
|
| |
|
|
|
|
|
|
| |
My best guess is that this was broken by d62dd8b0
Signed-off-by: Rob Clark <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3413>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3413>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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]>
|
| |
|
|
|
|
|
|
|
| |
Noticed while reviewing some lava parallel-deqp-runner changes.
Reviewed-by: Kristian H. Kristensen <[email protected]>
Reviewed-by: Rob Clark <[email protected]>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3138>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3138>
|
| |
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Eric Engestrom <[email protected]>
|
| |
|
|
|
| |
Signed-off-by: Samuel Pitoiset <[email protected]>
Reviewed-by: Michel Dänzer <[email protected]>
|
| |
|
|
|
| |
Signed-off-by: Rob Clark <[email protected]>
Acked-by: Eric Engestrom <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Extract .qpa for the individual unexpected results and flakes, and
translate to xml, preserved with the artifacts. This allows easy
browsing of the test logs for fails/flakes, for easier debugging.
The # of logs to preserve is capped at 50 to avoid saving 100s of
megabytes of logs in case someone pushes a change that breaks
everything.
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]>
|
| |
|
|
|
|
|
|
|
|
| |
Bump cts_runner to pick up the change to preserve .qpa and caselist .txt
files for blocks of tests that contain fails, and preserve the caselist
files. To reproduce fails that depend on order of running tests, these
are useful.
Signed-off-by: Rob Clark <[email protected]>
Acked-by: Eric Engestrom <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
The log only shows the first 50, but preserve the full list for easier
browsing.
(Also move return of exit code to end which makes later patches in the
series easier)
Signed-off-by: Rob Clark <[email protected]>
Acked-by: Eric Engestrom <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <[email protected]> (v1)
Reviewed-by: Tomeu Vizoso <[email protected]> (v2)
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If people fix bugs without updating the expected-fails list, then we
end up with a lack of coverage of those failures in the future. Also,
some day down the line another developer ends up trying to figure out
if the bug was actually fixed or their environment is just failing to
reproduce it.
Suggested-by: Kristian H. Kristensen <[email protected]>
Reviewed-by: Adam Jackson <[email protected]>
Acked-by: Rob Clark <[email protected]>
Reviewed-by: Kristian H. Kristensen <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
Sometimes you just want confirmation that dEQP really picked up the
driver we built you thought. This is not as good as one might like,
because git isn't present in the cross-build image.
Acked-by: Rob Clark <[email protected]>
Acked-by: Kenneth Graunke <[email protected]>
|
| |
|
|
|
|
|
|
|
| |
A handful of tests on freedreno have been close to the watchdog
timeout, and now sporadically fail since range analysis has slowed
down the compiler for them.
Acked-by: Rob Clark <[email protected]>
Acked-by: Kenneth Graunke <[email protected]>
|
|
|
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 <[email protected]>
|
