Some functionality has been added to deqp-volt to only print
regressions, so update our version of it and use the new options.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
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>
At the moment we don't have enough people to ensure that RK3288 is
regression-free, so don't fail the CI in that case.
For now we'll focus on not regressing on RK3399 and we can expand to
other SoCs as more people join the effort.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Suggested-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
As there's lots of them and Gitlab struggles rendering logs with so many
lines.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
These changes will make sure we get the right image from the container
registry.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
These three tests pass on RK3399, but fail on RK3288:
dEQP-GLES2.functional.shaders.matrix.div.const_lowp_mat2_mat2_vertex
dEQP-GLES2.functional.shaders.operator.unary_operator.pre_increment_effect.highp_ivec4_vertex
dEQP-GLES2.functional.shaders.texture_functions.vertex.texture2dprojlod_vec3
They reliably pass when run individually, but reliably fail when run in
a full CI run.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
These tests are failing at times, blacklist for now:
dEQP-GLES2.functional.fbo.render.shared_colorbuffer_clear.tex2d_rgba
dEQP-GLES2.functional.fbo.render.shared_colorbuffer_clear.tex2d_rgb
dEQP-GLES2.functional.shaders.matrix.mul.dynamic_highp_mat4_vec4_vertex
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
These are tests that regressed in RK3288 but still pass on RK3399.
So we still have a CI we can rely on, add them to the flip-flop list for
now.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Use the infrastructure in wayland/ci-templates to build the container
images.
This prevents from getting into some situations in which the images
wouldn't be rebuilt, and allows us to share some infrastructure with
other projects in freedesktop.org.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Suggested-by: Michel Dänzer <michel@daenzer.net>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Jump over the container stage if we haven't changed any of the files
that involved in building the container images.
This saves 1-2 minutes in each run and helps conserve resources.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Acked-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
To improve robustness, check that we got the expected number of results.
Right now we hard-code the expected number of tests run, but with some
effort we may be able to infer it.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
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>
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>
Tomeu Vizoso
Alyssa Rosenzweig