1. 12 Nov, 2020 1 commit
  2. 06 Nov, 2020 1 commit
    • Emma Anholt's avatar
      ci/deqp: Switch to a new dEQP runner written in Rust. · bf29daa1
      Emma Anholt authored
      
      
      I found the C++ runner hard to develop on, and we had stability issues and
      outstanding feature needs that made me want something I felt good about
      hacking on.  Thus, Rewrite It In Rust of the deqp runner.
      
      The new runner includes:
      
      - Skip lists don't reshuffle the test list.
      - Known-flake handling without resorting to skip lists (fixing our main CI
        reliability issue on a3xx right now).
      - Per-thread Vulkan shader caches should speed up VK CI runtime.
      - Tracking of crashes separate from fails (so we can see progress on that
        front).
      - Logging of deqp stderr spam (particularly assertion failures!) in the CI
        log.
      - Integrated QPA filtering so we don't have bash perf issues for it.
      - Logging of what caselist to go look at for a given error report (in red,
        so it's easier to find in your CI log).
      - The code is 1/3 unit tests, and easy to extend for more coverage.
      - Non-LAVA CI runs create a failures.csv in artifacts that you can check
        in as your deqp-*-fails.txt file.
      - Test runtime is included in results.csv so you can debug how to speed up
        your CI job.
      - Pretty summary at the end of the run of slow/flaky/failed tests.
      
      Since this is a new runner with a different RNG, the test groups are
      shuffled one more time.  This seems to result in some panfrost T720
      stability issues (See its new deqp-panfrost-t720-flakes.txt), and one new
      flake in freedreno a630.
      Reviewed-by: Tomeu Vizoso's avatarTomeu Vizoso <tomeu.vizoso@collabora.com>
      Part-of: <!7434>
      bf29daa1
  3. 30 Oct, 2020 1 commit
  4. 10 Oct, 2020 1 commit
  5. 09 Oct, 2020 1 commit
  6. 08 Oct, 2020 1 commit
    • Dave Airlie's avatar
      ci: enable piglit testing of clover/llvmpipe. · 0a172dca
      Dave Airlie authored
      
      
      This adds support for building clover/llvmpipe and running the
      piglit CL tests on it.
      
      It uses the gl testing container, and add builds the libclc
      spirv libraries as part of that which requires the llvm spirv
      translator in the build container.
      
      It also builds the llvm spirv translator as part of the build
      root and creates a mesa build that builds clover for testing
      against it. It uses llvm 10 as the baseline.
      
      This drops bswap as it has an oob memory access with llvmpipe
      which cause flaky test results. phatk also seems flaky
      Reviewed-by: Michel Dänzer's avatarMichel Dänzer <mdaenzer@redhat.com>
      Part-of: <!6901>
      0a172dca
  7. 01 Sep, 2020 1 commit
  8. 19 Aug, 2020 2 commits
  9. 17 Aug, 2020 1 commit
  10. 29 Jul, 2020 1 commit
  11. 02 Jun, 2020 2 commits
  12. 01 Jun, 2020 1 commit
  13. 28 May, 2020 2 commits
    • Michel Dänzer's avatar
      gitlab-ci: Pull in GCC 9 from Debian testing in x86_test-gl/vk images · 1fc1b877
      Michel Dänzer authored
      The GCC 8 packages from buster are no longer compatible with libc6 from
      testing. We could use the GCC 8 packages from testing instead, but this
      is easier.
      
      v2:
      * Update piglit-quick_gl test results, due to the piglit issue fixed by
        piglit!294
      
      Reviewed-by: Eric Anholt <eric@anholt.net> # v1
      Part-of: <!5186>
      1fc1b877
    • Michel Dänzer's avatar
      gitlab-ci: x86_test-base image as common base for x86_test-gl/vk · c2366f01
      Michel Dänzer authored
      Making use of the relatively recent FDO_BASE_IMAGE feature of the
      templates, the x86_test-base image contents are shared as a separate
      layer by the x86_test-gl/vk images (meaning the former only needs to be
      downloaded once for either or both of the latter). This should be more
      efficient in terms of overall network bandwidth and storage, in
      particular if the base image changes less often than the -gl/vk ones.
      
      v2:
      * List x86_test-base in needs: along with x86_test-gl/vk (see parent
        commit)
      * Always put $STABLE/TESTING_EPHEMERAL on separate lines, will make it
        easier to add any non-ephemeral packages
      
      Reviewed-by: Eric Anholt <eric@anholt.net> # v1
      Part-of: <!5186>
      c2366f01
  14. 18 May, 2020 1 commit
    • Pablo Saavedra's avatar
      ci: Migrate tracie tests done in shell script to pytest · 550a4f77
      Pablo Saavedra authored
      
      
      v2: Verbatim translation from the original shell script
          Make the corrections visible in explicit commits (Andres)
          Remove redundant code (Alexandros)
          Code style nitpick (Rohan)
      
      Reimplementation of the tracie's self-tests using a pythonic test suit
      (pytest).
      
      The new tracie/test.py module is almost a direct translation of the
      tests defined in the tracie/test.sh. This new implementation of the
      test provides a more common framework where define the tests.
      Also allows a better introspection for the tests results and/or
      resulting errors.
      
      This patch also adds python3-pytest as dependency for the built images
      and adapts the tracie-runner scripts to run the self-test using pytest.
      Signed-off-by: Pablo Saavedra's avatarPablo Saavedra <psaavedra@igalia.com>
      Reviewed-by: Alexandros Frantzis <alexandros.frantzis@collabora.com> [v1]
      Reviewed-by: Andres Gomez's avatarAndres Gomez <agomez@igalia.com>
      Reviewed-by: Rohan Garg <rohan.garg@collabora.com> [v1]
      Part-of: <!4916>
      550a4f77
  15. 14 May, 2020 1 commit
  16. 20 Apr, 2020 1 commit
  17. 17 Mar, 2020 2 commits
  18. 11 Mar, 2020 3 commits
  19. 20 Feb, 2020 1 commit
  20. 06 Feb, 2020 1 commit
  21. 07 Jan, 2020 1 commit
  22. 06 Dec, 2019 3 commits
  23. 21 Nov, 2019 1 commit
  24. 20 Nov, 2019 1 commit
  25. 15 Nov, 2019 2 commits
  26. 12 Nov, 2019 2 commits
    • Emma Anholt's avatar
      ci: Use cts_runner for our dEQP runs. · f08c8100
      Emma Anholt authored
      This runner is a little project by Bas, written in C++, that spawns
      threads that then loop grabbing chunks of the (randomly shuffled but
      consistently so) test list and hand it to a dEQP instance.  As the
      remaining list gets shorter, so do the chunks, so hopefully the
      threads all complete effectively at once.  It also handles restarting
      after crashes automatically.  I've extended the runner a bit to do
      what I was doing in the bash scripts before, like the skip list and
      expected failures handling.  This project should also be a good
      baseline for extending to handle retesting of intermittent failures.
      
      By switching to it, we can have the swrast tests just take up one job
      slot on the shared runners and keep their allotment of CPUs busy,
      instead of taking up job slots with single-threaded dEQP jobs.  It
      will also let us (eventually, once I reprovision) switch the freedreno
      runners over to threading within the job instead of running concurrent
      jobs, so that memory scribbles in one pipeline don't affect unrelated
      pipelines, and I can experiment with their parallelism (particularly
      on a306 where we are frequently backed up) without trashing other
      people's jobs.
      
      What we lose in this process is per-test output in the log (not a big
      loss, I think, since we summarize fails at the end and reducing log
      length keeps chrome from choking on our logs so badly).  We also drop
      the renderer sanity checking, since it's not saving qpa files for us
      to go poke through.  Given that all the drivers involved have fail
      lists, if we got the wrong renderer somehow, we'd get a job failure
      anyway.
      
      v2: Rebase on droppong of the autoscale cluster and the arm64
          build/test split.  Use a script to deduplicate the cts-runner
          build.
      v3: Rebase on the amd64 build/test container split.
      
      Acked-by: Daniel Stone <daniels@collabora.com> (v1)
      Reviewed-by: Tomeu Vizoso <tomeu.vizoso@collabora.com> (v2)
      f08c8100
    • Michel Dänzer's avatar
      gitlab-ci: Use separate docker images for x86 build/test jobs · aebf43dc
      Michel Dänzer authored and Michel Dänzer's avatar Michel Dänzer committed
      
      
      Same as was done for the ARM images before.
      
      This should make it less painful to update to newer dEQP / piglit as
      well as to make changes to the build/test environment.
      Reviewed-by: Emma Anholt's avatarEric Anholt <eric@anholt.net>
      aebf43dc
  27. 22 Oct, 2019 3 commits
  28. 12 Sep, 2019 1 commit
    • Emma Anholt's avatar
      freedreno: Introduce gitlab-based CI. · 6f0dc087
      Emma Anholt authored
      
      
      Since freedreno's kernel and GPU reset seem to be totally solid, we
      don't need to have the complexity of the LAVA setup that panfrost has.
      Instead, we can register some boards as shared gitlab runners and have
      the jobs run out of a docker container just like we do for llvmpipe.
      Just make sure that the DRI device node is passed through to the
      containers in the gitlab config ('devices = ["/dev/dri"]' under
      runners.docker).
      
      If a runner fails (networking dies, kernel panic, etc.) it'll take out
      one build but the rest can keep going since gitlab-runner is what
      pulls jobs.  Since the runner pulls jobs, it also means that they can
      live behind firewalls instead of needing some public address to be
      accessed by gitlab.fd.o.
      
      For now, enable it just on db410c (A307) and cheza (A630) as those are
      the hardware that I have plenty of.  A307 is only testing GLES2 since
      running all of GLES3 takes too long for the number of boards I've
      brought up.
      Acked-by: Rob Clark's avatarRob Clark <robdclark@chromium.org>
      Acked-by: Kenneth Graunke's avatarKenneth Graunke <kenneth@whitecape.org>
      6f0dc087