Thursday, August 7, 2014

Neat stuff for 3.17

So with the 3.16 kernel out of the door it's time to look at what's queued up for the Intel graphics driver in 3.17.

Wednesday, June 11, 2014

Documentation for drm/i915

So over the past few years the drm subsystem gained some very nice documentation. And recently we've started to follow suite with the Intel graphics driver. All the kernel documenation is integrated into one big DocBook and I regularly upload latest HTML builds of the Linux DRM Developer's Guide. This is built from drm-intel-nightly so has slightly freshed documentation (hopefully) than the usual DocBook builds from Linus' main branch which can be found all over the place. If you want to build these yourself simply run

$ make htmldocs

For testing we now also have neat documentation for the infrastructure and helper libraries found in intel-gpu-tools. The README in the i-g-t repository has detailed build instructions - gtkdoc is a bit more of a fuzz to integrate.

Below the break some more details about documentation requirements relevant for developers.

Tuesday, June 10, 2014

Neat drm/i915 stuff for 3.16

Linus decided to have a bit fun with the 3.16 merge window and the 3.15 release, so I'm a bit late with our regular look at the new stuff for the Intel graphics driver.

Wednesday, May 7, 2014

LinuxTag 2014

Tomorrow I'll be travelling to LinuxTag in Berlin for the first time. Should be pretty cool, and to top it off I'll give a presentation about the state of the intel kernel graphics driver. For those that can't attend I've uploaded the slides already, and if there's a video cut I'll link to that as soon as it's available.

Tuesday, April 1, 2014

Neat drm/i915 stuff for 3.15

So the release of the 3.14 linux kernel already happended and I'm a bit late for our regular look at what cool stuff will land in the 3.15 merge window for the Intel graphics driver.

Tuesday, February 4, 2014

New drm/i915 Git Repository

So earlier this year I've signed up Jani Nikula officially as co-maintainer. Now we've also gotten around to move the drm/i915 git repository to a common location so that there's no longer a need to move it around when I'm on vacation. So everone please update any git references and remotes:

FOSDEM: Testing Kernel GPU Drivers

So as usual FOSDEM was a blast and as usual the hallway track was great too. The beer certainly helped with that ... Big props to the entire conference crew for organizing a stellar event and specifically to Luc and the other graphics devroom people.

I've also uploaded the slides for my Kernel GPU Driver Testing talk. My OCD made me remove that additional dot and resurrect the missing 'e' in one of the slides even. FOSDEM also had live-streaming and rendering videos should eventually show up, I'll add the link as soon as it's there.

Update: FOSDEM staff published the video of the talk!

Wednesday, January 15, 2014

Neat drm/i915 stuff for 3.14

Kernel v3.13 is nearing its release, so it's time at our regular look at what the next version will bring to the Intel gfx driver.

Friday, November 22, 2013

Botching up ioctls

One clear insight kernel graphics hackers gained in the past few years is that trying to come up with a unified interface to manage the execution units and memory on completely different GPUs is a futile effort. So nowadays every driver has its own set of ioctls to allocate memory and submit work to the GPU. Which is nice, since there's no more insanity in the form of fake-generic, but actually only used once interfaces. But the clear downside is that there's much more potential to screw things up.

To avoid repeating all the same mistakes again I've written up some of the lessons learned while botching the job for the drm/i915 driver. Most of these only cover technicalities and not the big-picture issues like what the command submission ioctl exactly should look like. Learning these lessons is probably something every GPU driver has to do on its own.

Tuesday, November 12, 2013

Testing Requirements for drm/i915 Features and Patches

I want to make automated test coverage an integral part of our feature and bugfix development process. For features this means that starting with the design phase testability needs to be considered an integral part of any feature. This needs to go through the entire development process, from planning, development, patch submission and final validation. For bugfixes that means the fix is only complete once the automated testcase for it is also done, if we need a new one

This specifically excludes testing with humans somewhere in the loop. We are extremely limited in our validation resources, every time we put something new onto the "manual testing" plate something else will fall off.

I've let this float for quite a while both internally in Intel and on the public mailing lists. Thanks to everyone who provided valuable input. Essentially this just codifies the already existing expectations from me as the maintainer, but those requirements haven't really been clear and a lot of emotional discussions ensued. With this we should now have solid guidelines and can go back to coding instead of blowing through so much time and energy on waging flamewars.