Arek Hiler

IGT recently underwent quite a few changes. The name is now vendor-agnostic, meson is the new default build system, we are on the GitLab, and the new runner, a piglit replacement, has landed.

So what's up with the name change from "Intel GPU Tools" to "IGT GPU Tools"? Is it just GNU, with its sweet recursiveness, being that inspiring or do we really belive that having a vendor agnostic test suite that benefits the whole DRM subsystem is important?

Let's also talk build system. Everyone, and their dog, is switching to Meson nowadays, so we have too jumped on the bandwagon. How has the switch went? How does Meson compare to autotools? Are we going to remove the old build system... and when is that going to happen?

GitLab and its CI/CD pipleine allows us to generate and publish documentation efortlessly, get us cross-compilation working and run some post-merge autotools/meson consistency checs.

There is also the new runner. Are we suffering from "Not Invented Here" syndrome or it there actual, compelling reason to do all the extra development? This allows us to drop Python as a dependency and have a way to run a single binary with multiple subtests in one go, instead of spawning a new process for each subtest which does the same initialization, and shaving off those sweet sweet seconds so we can squeeze even more CI runs in a day.

In this talk, we highlight how important automated testing is to sustain the upstream development model of Linux, especially when products are involved. We will then give you a tour of our system, how it integrates with the developer's workflow, what we are working on, and we managed to grow from a couple of thousands tests executed per week to over 4 millions!

We will also present the changes we have done to the IGT test suite to become less Intel-specific and serve the needs of multiple drivers.

Upstream development requires never regressing the features that were already present in previous versions. We believe that this is not only the right thing to do, it is also increasing in relevance as more and more products move towards this model. To embrace this model, we try to catch unintentional regressions as early as possible through our CI system. This improves the productivity of our developers (fewer bugs coming months after the code was committed), and provide users with a smoother upgrade path (either through the product manufacturer or by upgrading the kernel themselves).

The Intel GFX CI has grown massively in the past 1.5 years: the number of machine doubled; the test coverage went from 260 tests/machine up to over 4k; the number of tests executed went from 100k/week to over 4M; pre-merge testing time dropping to an average of 30 minutes despite the increased usage.

We will then tour the audience through our different services, how they integrate with the developers' workflow, and how we manage to keep track of failures (and file them).

Finally, we will share what are our current developments, our goals, and what we are doing to the IGT test suite in order make it useful for more drivers than Intel.