Emma Anholt

When Google was looking at shipping laptops with Qualcomm hardware, I was tapped to be the second member of a team responsible for reverse-engineering Qualcomm's closed-source GL/Vulkan drivers to build drivers suitable for ChromeOS. I was proud to work with Valve engineers also working on the Turnip (Vulkan driver) project, and together we built a conformant VK 1.1 implementation, now exposing VK 1.4. I chased down performance gaps, and got us to 101% (ANGLE) and 85% (zink) performance of GLES traces running on our driver compared to the native open source GLES driver.

I was also lucky to get to spend a significant amount of time improving the core of the Mesa project -- removing old intermediate layers in the OpenGL drivers (TGSI compiler IR), reducing cross-driver binary size, and helping transition the GLSL compiler to NIR and delete code in the process.

Finally, I drove moving Mesa from individual developers testing their code on what hardware they had on hand which they thought might be affected, to an automated central CI system based on Graydon Hoare's "Not Rocket Science" rule. Now merging code is gated on proving that you don't regress any driver in the codebase on the CTS, white-box non-CTS tests that Mesa maintains, or rendering of actual application traces. It was a rocky road, but it was a dramatic change to no longer have one's driver break on a monthly to weekly basis by common code changes from other developers, or be bisecting old regressions trying to get a stable release out the door. It also reduced code review overhead once we could trust that we only had to review for code quality and architectural direction, not whether changes would outright break other drivers.

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. Leveraging Mesa, I built a faster driver than the closed source team had, as a solo project.

My responsibilities included developing a Gallium-based Mesa OpenGL/GLES 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 was 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 other external contributions, I worked with them and the developers above them to take over the role of merging patches for the platform (bcm2835).

I took 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 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, then served as treasurer.

I serve on the board of TPMS as the finance committee chair.