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.3.

I have also worked to shrink the size of all Mesa driver binaries to keep ChromeOS's rootfs under control, cut out old compiler stages and passes from the tree, and built a gitlab-based CI system for various QC hardware that is also used by the etnaviv and Broadcom GL/VK Mesa driver projects.

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. I then continued on to build the GLES/GL driver for the next generation ("v3d", for the v3d v3.3-v4.2 architectures) that appeared in the Raspberry Pi 4.

My responsibilities included developing Gallium-based Mesa OpenGL/OpenGL ES drivers, 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 code from myself or others, 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 in my first round, and served as treasurer in the second.

I serve as a volunteer with a regional Burning Man-associated festival, and have worked in the Gate, DPW (site setup/teardown), and Fire Safety (hose team) departments. In 2019 the Power and Communication department leads stepped down, and I stepped in to serve that role (radio repeater setup and support, radio distribution, and power distribution) as a lead, building documentation on department operations that had been completely missing.