Martin Peres

The Linux community is slowly moving towards better quality trough automated testing to prevent regressions in mainline and stable trees. However, Linux is full of HW-specific code which makes validation of patches impossible for individual developers, which leads to regressions. In this talk, we will explain how we solved these issues by getting inspired by Linux's development model, and how we extend it to the development of our testsuite, CI infrastructure and bug handling.

After 2 years of activity, this led Linus Torvalds to say i915's quality has greatly improved compared to other graphic drivers.

Linux's development model has been described as being akin to a bazaar, where any developer can make changes to Linux as long as they strictly improve the state of Linux, without regressing any application that currently runs on it. This allows Linux users to update their kernels and benefit from the work of all developers, without having to fix anything in their applications when a new version comes. Unfortunately, it is impossible for developers to try their changes on all the different hardware and userspace combination being used in the wild.

Typically, a developer will mostly test the feature he/she is working on with the hardware at hand before submitting the patch for review. Once reviewed, the patch can land in a staging repository controlled by the maintainer of the subsystem the patch is changing. Validation of the staging tree is then performed ahead of sending these changes to Linus Torvalds (or one of his maintainers). Regressions caught at this point require to bisect the issue, which is time consuming and usually done by a separate team, which may become a bottleneck. Sometimes they let regressions through, hoping to be able to fix them during the -rc cycles.

To address this bottleneck, the developer should be responsible for validating the change completely. This leads to a virtuous cycle as not only developers can rework their patches until they do not break anything (saving the time of other people), but they also become more aware of the interaction their changes have on userspace, which improves their understanding of the driver which leads to better future patches.

To enable putting the full cost of integration on developers, validation needs to become 100% automated, have 100% code/HW coverage of the userspace usecases, and provide timely validation results to even the most time-pressured developers. To reach these really ambitious objectives, driver developers and validation engineers need to be considered as one team. The CI system developers need to provide a system capable of reaching the objectives, and driver developers need to develop a test suite capable of reaching the goal of having 100% code coverage of the whole driver on the CI system provided to them.

Finally, this increase in understanding of how validation is done allows developers to know if their patch series will be properly validated, which reduces the risk of letting regressions land in Linux.

The devil however lies in the details, so in this talk, we will explain how we are going from theory to practice, what is our current status and what we are doing to get closer to our ambitious goal! We will describe the current developer workflow and demonstrate how we empowered developers by providing timely testing as a transparent service to anyone sending patches to our mailing lists.

Brief update on the Nouveau project.

We want to talk about what we have done on over the past year(s) and what we are planning to work on in the near future. Main topics will be power management, Nvidia and community.

Other people: Pierre Moreau Karol Herbst

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.

Other people: Arek Hiler

At XDC2015, I presented some of the pitfalls of benchmarking Graphics applications and announced the Open Source EzBench project which aims at automating data collection and bisecting performance changes while avoiding those pitfalls.

This presentation will recap some of the nasty issues with benchmarking and present EzBench along with how to use it.

Nouveau is an open-source driver for NVIDIA GPUs developed through reverse engineering by the community. This talk will discuss the achievements of the driver, what happened these last 2 years, what we are working on and what may change in the future. Special emphasis will be put on power management as it is the most-lacking feature in our driver. Some demos and Q&A will close the talk.

The state of the FLOSS graphics stack is rapidly changing and so is the X.org foundation. We are currently working on merging with SPI to get rid of the bureaucracy that goes along with having the non-profit association status in the USA (501(c)(3)). Since we are changing our legal status, it is also grand-time for us to broaden our purpose beyond the X Windowing System. Projects like Mesa and Wayland have accepted to be placed under the X.org foundation umbrella, it is time for us to make it clear that the X.org foundation is not only about X anymore! This talk will also advise people to become members of the foundation in order to get a voice in this process.

This talk will walk the audience through the graphics stack and then concentrate on scenarios where the Graphics Stack is not secure. Lastly, we will talk about the upgrades to DRM and the DRI2 protocols that are currently being done

During this talk we will survey the current state of security in the Linux Graphics Stack and illustrate the problem with real-life scenarios.

We will then explain the source of these problems, describe how they interact with the X and Wayland infrastructures and discuss the solutions currently deployed to mitigate those issues.

This will lead us to the current work on DRI and DRM, known under the names DRI-next and drm2/render nodes.

Other people: Timothée Ravier

This talk is about the Linux open-source driver for nVidia GPUs (desktop and laptop). It will start by a recap of the history of this open source driver. The talk will then continues by detailing the current (and future) state of the following components: - DRM + ddx: Modesetting & 2D - Mesa: 3D - Power Management Some demonstrations will also be performed such as video decoding and power management. Finally, this talk will also allow you to interact with many Nouveau developers and ask your questions directly.

Other people: Lucas Stach