I've been hacking on open source graphics since I first wanted to play Quake 3 on my 3DFX as a kid and my drivers didn't work. A desire to play videogames evolved into a passion for driver development that continues to this day.
When Broadcom announced the release of documentation for the VC4 chipset (the GPU in the Raspberry Pi), I joined them to build a new open source Linux graphics driver to replace their existing closed source stack.
My responsibilities included developing a Gallium-based Mesa OpenGL driver, kernel side command execution and memory management driver, and the display driver including the HDMI, DPI, and DSI encoder subdrivers.
One of the challenges of the VC4 architecture is the lack of MMU between the 3D engine and main memory shared with the ARM core. To ensure system security, I borrowed ideas from Google's NaCl and engineered my GLSL compiler backend to emit idiomatic shader assembly that I could easily validate in my Linux kernel driver.
I joined Keith Packard at Intel to form the new Linux graphics team when the driver development was being brought in house. Starting with Linux graphics a decade behind mainstream OSes, we worked together to modernize Linux graphics architecture.
One of my key accomplishments was building the GEM (graphics execution management) memory management architecture. The previous allocator was entirely cooperatively managed in userspace to reduce kernel requirements, at the cost of all graphics memory contents being considered disposable. Working with Keith, I built a new memory management architecture in the kernel, tightly coupled with the Linux VM, allowing GPU memory to be stable across context switches and even swapped to disk under memory pressure. My interface design is still used across multiple drivers for fast command stream generation in the presence of movable underlying memory allocations.
A second major accomplishment was writing the GLSL compiler backend. In order to get GL 2.0 not just working but performing as it should, I had to move the driver from an assembler-style opcode translator to a complete compiler backend. While other members of the team worked more on the frontend, I wrote the new code generator, register allocator, copy propagation and register coalescing, and various peephole passes.
I have twice served as a Linux kernel maintainer. The first was at Intel for the kernel side of our graphics driver.
The second has been at Broadcom. The Raspberry Pi Foundation's Linux port had only been partially upstreamed by volunteers. In the process of building my graphics driver, I needed to write new platform drivers (clock, power, firmware communication) necessary for graphics, and when the existing maintainers were too overloaded to merge my code and others, I worked with them and the developers above them to take over the role of merging patches for the platform (bcm2835).
I take my role as a kernel maintainer seriously, providing timely review to patch submissions and working to exemplify the more civil, supportive environment I want on technical mailing lists. To provide quality patch review, I taught myself Verilog so that I could authoritatively answer questions about hardware behavior. And, of course, in my tenure I've had to review or work on almost every part of the platform, including the drivers for irqchip, smp, dmaengine, spi, i2c, uart, gpio, clk, power, mmc, hw_random, and thermal, and the devicetree gluing them all together.
I was elected as a board member in the reconstructed X.Org Foundation. I managed membership and the backend of running elections.
Getting the job done has sometimes involved spawning new open source projects. Here are a few I'm proud of: