Interview: Chris Wilson, Open Source Graphics Hacker

By Dawn M. Foster (91 posts) on January 12, 2010 at 8:00 am

Chris Wilson worked in a defense research agency learning how to measure children's feet, a most appropriate use of military technology, until he saw the error of his ways. A few years ago, he left to work on open source technology and became one of Keith Packard's minions in Aug '09 joining Intel's Open Source Technology Center.

Dawn: What do you like about working in Intel's Open Source Technology Center?

Chris: First and foremost, it would be the challenge. Making hardware work is difficult, making it work well is even tougher, and doing it in the open, where your work will be critiqued by the seasoned veteran looking for embarrassing mistakes and the student who wishes to learn and to participate, is invigorating. The real challenge is writing beautiful code that not only works well, but that which we can be proud of. And the thrill of working in the OTC is working alongside some of the world's best and most respected hackers.

Dawn: Can you tell us more about your work on the Graphics Execution Manager (GEM) and Cairo?

Chris: I've been working on Cairo for a few years now, ever since discovering it whilst writing user interfaces for realtime systems. It has just a single job, to convert paths into native representations -- i.e. paths and pen commands for vector output such as PDF or PS for printing, or into geometry which can be pushed to GPUs. This means that Cairo presents an elegant and minimal interface to the application and hides all the complexity of accelerating graphics across a broad range of platforms.

In my work, I have focused on performance. People have always claimed that Cairo is slow, so I tackled that. We now have a set of "real world benchmarks" which are comprised of a series of recorded traces taken from applications performing every day tasks (such as reading email in evolution and browsing news sites with Firefox). Having a set of traces means that we can measure the impact of any change upon system performance and how that will relate to perceived throughput. (Latency is another critical factor in perceived performance, as is trying to capture worst case behaviour. Tackling those so that the system always feels responsive under load is a future goal.) With the confidence from the reproducible benchmarks, I have been able to make sweeping changes across Cairo and have found many areas where we were not quite as efficient as we needed to be. For some workloads, I have been able to improve Cairo's performance by over an order of magnitude.

However, my work does not end with Cairo. Using the same Cairo benchmarks, we can investigate why our drivers are so slow. These factors are many-fold, like too much overhead in the kernel or not exposing sufficient hardware features that are required by the userspace drivers. More often than not, our userspace Xorg driver is simply not performant and is missing acceleration paths. Over the longer term, we are looking for ways we can implement new algorithms, which should significantly improve our performance and reduce power consumption. As part of that, GEM (which moves the complexity of memory management into the kernel and out of the application, leaving the application with the task of simply issuing drawing commands) allows us to experiment with novel rendering methods within Cairo itself. This has greatly simplified writing new acceleration methods, and has given further impetus to reduce the remaining overhead within Cairo.

Dawn: At the Linux Plumbers Conference in September, you talked about the battle for 2D acceleration. What have you been doing to improve it?

Chris: Under Linux, Cairo is perhaps the most performant graphics library, at least by my measurements! Sadly it is not used as widely or as well as I would like it to be, and the driver support is not as good as it should be.

The topic for the talk was essentially, "how can we remedy the driver situation?" The presentation itself was given on an EeePC 700 with an i915, running at 25fps. That level of performance is currently impossible using Xorg and the -intel drivers, or even using OpenGL on that hardware.

cairo-drm (that is Cairo with a backend that talks directly to the GPU) is many times faster than our current -intel driver, and unlike the -intel driver, is actually faster than using the CPU. cairo-drm provides a good technology demonstration of what the absolute performance limits of a particular chipset. (Presuming that cairo-drm is itself well written!)

On the other hand, cairo-gl (Cairo with an OpenGL backend that also talks directly to the GPU) was even slower (by an order of magnitude in some cases) than the -intel Xorg driver. [Don't even mention cairo-glitz, that is many times slower than cairo-gl.] This is disappointing since using OpenGL gives an abstraction layer that should allow us to approach cairo-drm performance levels across all GPUs -- it allows us to focus on writing just one driver.

Pragmatically, Xorg is here to stay, and so I have been looking at how we can feed all the improvements from cairo-drm into our driver. Meanwhile, I've been also looking at how applications could use cairo-drm to bypass the current slow drivers.

Dawn: What do you do for fun when you aren't working at Intel?

Chris: My main interests are playing hockey and running. I originally started running just as a means of getting fit and gaining a place in the University side, and now I need to run to keep up with all the younger and faster players. However, running I have found to be good fun whether by myself or with the comradery of the Whippets, the local running club.

Categories: Open Source
Tags: , , , , , ,

For more complete information about compiler optimizations, see our Optimization Notice.

Comments (0)

Trackbacks (5)


Leave a comment  

To obtain technical support, please go to Software Support.
Name (required)*

Email (required; will not be displayed on this page)*

Your URL (optional)


Comment*