Thursday, April 21, 2016

Validating changes to KMS drivers with IGT

New
DRM drivers are being added to almost each new kernel release, and
because the mode setting API is so rich and complex, bugs do slip in that
translate to differences in behaviour between drivers.

There
have been previous attempts at writing test suites for validating
changes and preventing regressions, but they have typically happened
downstream and focused on the specific needs of specific products and
limited to one or at most a few of different hardware platforms.

Writing
these tests from scratch would have been an enormous amount of work,
and gathering previous efforts and joining them wouldn't be much worth
it because they were written using different test frameworks and in
different programming languages. Also, there would be great overlap on
the basic tests, and little would remain of the trickier stuff.

Of the existing test suites, the one with most coverage is intel-gpu-tools, used by the Intel graphics team. Though a big part is
specific to the i915 driver, what uses the generic APIs is pretty much
driver-independent and can be made to work with the other drivers
without much effort. Also, Broadcom's Eric Anholt has already started
adding tests for IOCTLs specific to the VideoCore-IV driver.

Collabora's
Micah Fedke and Daniel Stone had added a facility for selecting DRM device files
other than i915's and I improved the abstraction for creating buffers so
it works for drivers without GEM buffers. Next I removed a bunch of
superfluous dependencies on i915-only stuff and got a useful subset of
tests to run on a Radxa Rock2 board (with the Rockchip 3288 SoC). Around
half of these patches have been merged already and the other half are
awaiting review. Meanwhile, Collabora's Robert Foss is running the
ported tests on a Raspberry Pi 2 and has started sending patches to
account for its peculiarities.

The
next two big chunks of work are abstracting CRC checksums of frames (on
drivers other than i915 this could be done with Google's Chamelium or
with a board similar to Numato Opsis),
and the buffer management API from libdrm that is currently i915-only
(bufmgr). Something that will have to be dealt with in the future is
abstracting the submittal of specific loads on the GPU as that's
currently very much driver-specific.

Additionally, I will be scheduling jobs in our LAVA instance to run these tests on the boards we have in there.

Thanks
to Google for sponsoring my time, to the Intel OTC folks for their
support and reviews, and to Collabora for sponsoring Robert's, Micah's
and Daniel's time.