How to approach a new system: Linux graphics and Mesa

By now, most of the Linux world knows I’ve stopped working on the Linux kernel and I’m starting work on the Linux graphics stack, specifically on the userspace graphics project called Mesa.

What is Mesa?

Like the Linux kernel, Mesa falls into the “operating system plumbing” category. You don’t notice it until it breaks. Or clogs, slowing down the rest of the system. Or you need plumbing for your shiny new hot tub, only you’re missing some new essential feature, like hot water or tessellation shaders.

The most challenging and exciting part of working on systems “plumbing” projects is optimization, which requires a deep understanding of both the hardware limitations below you in the stack, and the needs of the software layers above you. So where does Mesa fit into the Linux graphics stack?

Mesa is the most basic part of the userspace graphics stack, sitting above the Linux kernel graphics driver that handles command submission to the hardware, and below 3D libraries like qt, kde, or game engines like Unity or Unreal. A game engine creates a specialized 3D program, called a shader, that conforms to a particular rev of a graphics spec (such as EGL 3.0 or GLES 3.1). Mesa takes that shader program and compiles it into graphics hardware commands specific to the system Mesa is running on.

What’s cool about Mesa?

The exciting thing for me is the potential for optimizing graphics around system hardware limitations. For example, you can optimize the compiler to generate less graphics commands. In theory, less commands means less for the hardware to execute, and thus better graphics performance. However, if each of those commands are really expensive to run on your graphics hardware, that optimization can actually end up hurting your performance.

This kind of work is fun for me, because I get to touch and learn about hardware, without actually writing Verilog or VHDL. I get to make hardware do interesting things, like add a new features that makes the latest Steam game actually render or add an optimization that improves the performance of a new open source Indie game.

Understand how much you don’t know

Without knowledge of both the hardware and software layers above, it’s impossible to evaluate what optimizations are useful to pursue. For example, the first time I heard modern Intel GPUs have a completely separate cache from the CPU, I asked two questions: “What uses that cache?” and “What happens when the cache is full?” The hardware Execution Units (EUs) that execute graphics commands use the cache to store metadata called URBs. My next question, on discovering that URB size could vary, and that newer hardware had an ever-increasing maximum URB size, was to ask, “How does the graphics stack pick which URB size to use?” Obviously, picking a smaller URB size means that more URBs can fit in the cache, which means it’s less likely that an EU will have to stall until there’s room in the cache for the URB it needs for the set of graphics commands its executing. Picking an URB size that was too small would mean programs that use a lot of metadata wouldn’t be able to run.

Mesa is used by a lot of different programs with different needs, and each may require different URB sizes. The hardware has to be programmed with the maximum URB size, and changing that requires stopping any executing commands in the graphics pipeline. So you can’t go changing the URB size on the fly every time a new 3D graphics program starts running, or you would risk stalling the whole graphics stack. Imagine your entire desktop system freezing every time you launched a new Steam game.

Asking questions helps you ramp faster

It’s my experience with other operating system components that lead me to ask questions of my more experienced graphics developer co-workers. I really appreciate working in a community where I know I can ask these kinds of basic questions without fear of backlash at a newcomer. I love working on a team that chats about tech (and non tech!) over lunch. I love the easy access of the Intel graphics and DRI irc channels, where people are willing to answer simple questions like “How do I build the documentation?” (Which turns out to be complex when you run into a bug in doxygen that causes an infinite loop and increasing memory consumption until a less-than-capable build box starts to freeze under memory pressure. Imagine what would have happened if the experienced devs assumed I was a n00b and ignored me?)

My experience with other complex systems makes me understand that the deep, interesting problems can’t be approached without a long ramp up period and lots of smaller patches to gain understanding of the system. I do chafe a bit as I write those patches, knowing the interesting problems are out there, but I know I have to walk before I start running. In the meantime, I find joy in making blog posts about what I’m learning about the graphics pipeline, and I hope we can walk together.

8 thoughts on “How to approach a new system: Linux graphics and Mesa

  1. I like the community/team as well. I spend a lot of time talking to them about desktop stuff. It’s really quite cool.

  2. Thanks for writing this, Sarah – I found your blog through a Geek Feminism report of your ‘Closing a Door’ post on leaving the Linux kernel community, and it’s awesome to see this little view into a cool bit of How Linux Works! I’m glad you’re finding it welcoming there so far.

    Also, I’m a long-term Linux user who’s just recently started geeking professionally, and the ‘asking questions helps’ bit of this has held so true for me doing sysadmin things! I’ve been jumping between designing automation for physical machines and AWS ones and soon VMware in the space of a couple of months. So many exciting new projects, and so much cool new insight into complex problems.

    Anyway, I’ve always wanted to dive into a big open source project some day, and I think that when that time comes, the writing you’ve put out here about what makes a good community is going to help out a lot. Thanks, and all the best with Mesa!

  3. Daniel Vetter has a really well-written layer-by-layer introduction to the operation of Intel’s GPU hardware on his blog. I don’t know how much has changed in Intel’s later hardware generations, but in case you haven’t come across it yet the first article in the series can be found at:

    Best of luck with your new endeavour!

  4. Mesa isn’t plumbing, Mesa is a very difficult project. 3D developers are known to write the worst code in whole linux. Maybe you can help there

    1. I didn’t mean to imply that plumbing is easy work. It’s just that no one thinks of it until it breaks. You may not have heard of the Linux Plumbers Conference, which includes such software plumbing like the kernel, dbus, systemd, Wayland, etc. And yes, I do hope to help out, thanks!

  5. Sorry if it’s a silly question, I’ve been curious for a long time. Is heterogeneus GPU rendering possible?

    E.g. nowadays many PCs have multiple GPUs — one integrated into CPU, and one discrete. Usually, rendering of a particular app is done with a single GPU (excluding proprietary technologies, like NVidia SLI, which anyway does require GPUs to be either of the same model, or, at least, vendor). So, have Mesa devs ever discussed a possibility to render the same app via multiple distinct GPUs?

Comments are closed.