Commit 4fd36bd0 authored by Arkadiusz Hiler's avatar Arkadiusz Hiler

Add the new index page

Signed-off-by: Arkadiusz Hiler's avatarArkadiusz Hiler <>
This work is licensed under the Creative Commons Attribution 4.0 International
License. To view a copy of this license, visit or send a letter to Creative
Commons, PO Box 1866, Mountain View, CA 94042, USA.
# Intel GFX CI
## What Is It About?
We are continously testing [i915][i915-desc] (a Linux kernel device driver
for Intel Graphics) in an automated fashion, with a goal of having production
ready upstream.
## Hardware List
Our CI system is composed of multiple Intel machines spanning many
generations and display types. You can find our full hardware list here:
* [list of machines](/hardware.html)
* [raw data dump](/hardware/) (dmidecode, various debugfses, etc.)
## Pre-Merge Testing
**This is the crux of this CI system.** We test each patch that goes in our
driver ([i915][i915-desc]) or in the DRM drivers test suite we use ([IGT GPU
Tools][igt-desc]) before it lands in the repository and compare the results
with the [post-merge baseline](#git-trees-tested-post-merge) ([we filter out
known bugs](#results-filtering-and-bug-tracking)). This shifts the cost of
integration on the people making the change and helps us avoid time-consuming
bisection and reverts.
Since we accept patches through mailing lists, this is where you can find the
results - they are sent out as a replies to the original mail. Here are the
mailing lists we currently support:
| Mailing List | List Info | Archive | [Patchwork][patchwork-desc] |
| -- | -- | -- | -- |
| | [info][intel-gfx-info] | [archive][intel-gfx-arch] | [patchwork][intel-gfx-pw] |
| | [info][igt-dev-info] | [archive][igt-dev-arch] | [patchwork][igt-dev-pw] |
| | [info][trybot-info] | [archive][trybot-arch] | [patchwork][trybot-pw] |
### Queues
You can check our pre-merge queue for ([BAT](#basic-acceptance-tests-aka-bat)
only!) at <>.
Intel-GFX-CI queue (kernel patches) has priority over IGT queue and will be
drained first. Trybot is best-effort and has the lowest priority.
## Git Trees Tested Post-Merge
We test many trees post-merge. Some of them are our baseline for pre-merge
testing (drm-tip and IGT GPU Tools), while the others helps us to make sure
that what we submit upstream works and catch any potential issues cased by
changes in other drivers/trees before we actually integrate with them.
The testing is sparse, i.e. we poll the branch for changes periodically, and
if something has changed we run it through our CI, even if that means
multiple commits/merges.
| ISSUES | Documentation | Repository |
| -- | -- | -- |
| [drm-tip][] | [docs][drm-tip-doc] | [repo][drm-tip-repo] |
| [IGT GPU Tools][drm-tip]<sup>*</sup> | [docs][igt-doc] | [repo][igt-repo] |
| [Linus' tree][linus] | ??? | [repo][linus-repo] |
| [linux-next][] | [docs][linux-next-doc] | [repo][linux-next-repo] |
| [drm-intel-fixes][drm-intel-fixes] | [docs][drm-intel-doc] | [repo][drm-intel-fixes-repo] |
| [drm-intel-next-fixes][dinf] | [docs][drm-intel-doc] | [repo][dinf-repo] |
| [drm-intel-next-queued][dinq] | [docs][drm-intel-doc] | [repo][dinq-repo] |
| [drm-misc-fixes][drm-misc-fixes] | [docs][drm-misc-doc] | [repo][drm-misc-fixes-repo] |
| [drm-misc-next-fixes][drm-misc-next-fixes] | [docs][drm-misc-doc] | [repo][drm-misc-next-fixes-repo] |
| [Dave Airlie's branch][airlied] | ??? | [repo][airlied-repo] |
*\*: IGT results are part of the drm-tip visualisation*
[drm-tip]: /tree/drm-tip/
[linus]: /tree/linus/
[linux-next]: /tree/linux-next/
[drm-intel-fixes]: /tree/drm-intel-fixes/
[drm-intel-fixes-repo]: /tree/drm-intel-fixes/
[dinf]: /tree/drm-intel-next-fixes/
[dinq]: /tree/drm-intel-next-queued/
[drm-misc-fixes]: /tree/drm-misc-fixes/
[drm-misc-next-fixes]: /tree/drm-misc-next-fixes/
[airlied]: /tree/airlied/
## Results Filtering And Bug Tracking
Bugs caught by our system are filled to the following bug trackers:
* [freedesktop's bugzilla][fdo-bugzilla] - all things IGT and DRM
* ['s bugzilla][korg-bugzilla] - all other upstream bugs
We also maintain a set of filters that tie those bugs to failures we see in
our CI using machine names/types and patterns in dmesg/test output. This way
we are able to filter known issues out of pre-merge results to decrease noise
for developers, keep track of bug's life cycle, and reproduction rate. The
tool makes us able to confirm that a supposed fix is indeed fixing things.
You can **browse the CI issues** with the related data using our tool called
[cibuglog][] (updated hourly).
## The Kinds Of Runs
### Basic Acceptance Tests (aka BAT)
BAT is the most basic run in our portfolio - it consists of tests that help
us ensure that the testing configuration is in a working condition. It gates
all the sharded runs - if it breaks, then the build is deemed to broken to
use more of the CI time on it. It utilizes [fast-feedback.testlist][], which
you can find in the IGT repository.
### Full IGT (aka sharded runs)
If the BAT run is succesful, then we continue with the sharded run. Much
broader set of tests (everything you can find in IGT filtered through our
[blacklist.txt][]) is executed.
### Idle Runs
Those runs are complementary to the ones above, used mainly to gather extra
data and increase coverage. As the name suggests, they are run when CI would
be idle otherwise (i.e. there nothing to test for the regular
- [drmtip][drmtip-results] - Full IGT but on the same hosts that BAT uses,
thus increasing coverege.
- [KASAN][kasan-results] - same as above but runs with
[The Kernel Address Sanitizer][kasan] enabled.
- 100 reruns - rerun BAT 100 times with fixed IGT and kernel for extra data
on flip-floppers.
[drmtip-results]: /tree/drm-tip/drmtip.html
[kasan-results]: /tree/drm-tip/kasan.html
## Contacts
* **IRC:** #intel-gfx @ freenode
* **hardware/CI maintainer:** Tomi Sarvela - tomi.p.sarvela @
* **cibuglog/metrics maintainer:** Martin Peres - martin.peres @
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment