Graphics linkspam: A maze of twisty passages

One of the things I’ve been frustrated with lately is an overview document of Intel graphics architecture. There’s the massive Intel graphics Programmer Reference Manuals (which are so big they need to be separate PDFs for each chapter), but if you’re skimming each chapter intro for an overview, you’re likely to get lost. Fortunately, I stumbled across a 22-page Intel graphics architecture overview document that looks much more promising.

Another cool find this week was two sites that document which OpenGL extensions hardware manufacturers implement on Linux. If you’re a game designer looking to improve performance by using the latest wiz-bang extension, it’s important to know if that extension is actually implemented in all the hardware you care about. There’s the Mesa Matrix site that says whether a particular hardware vendor implements an extension, and another site that further breaks it down per-platform.

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.

OPW Successes and Succession Planning

It’s been a busy winter for the FOSS Outreach Program for Women (OPW).  On October 13, 2014, seven (yes, seven!) of the former Linux kernel OPW interns presented their projects at LinuxCon Europe.  From left to right, the OPW alumni are: Valentina Manea, Kristina Martšenko, Ana Rey, Sarah Sharp (coordinator), Himangi Saraogi, Teodora Băluţă, Andreea-Cristina Bernat, and Rashika Kheria.

OPW Kernel Interns & Coordinator at LinuxCon Europe 2014

The OPW presentation room was packed, and I had a couple Linux kernel developers come up to me afterwards and say, “I didn’t realize how complex some of the projects were!”  The OPW Linux kernel interns presented their work on Staging IIO drivers, Coccinelle, RCU, removing tree-wide warnings to allow more gcc warnings flags to be turned on, USB over IP, displaying kernel oopses in QR codes, and netfilter tables.  Slides are available here.

I’d like to thank the Linux Foundation for covering additional travel costs for several of the interns.  I would also like to thank the internship sponsors, Intel, Linux Foundation, Linaro, and Codethink.  Finally, this year’s internships could not have been possible without the time volunteered by our Linux kernel mentors: Adrian Chadd, Bob Copeland, Andy Grover, Nick Kossifidis, Greg Kroah-Hartman, Paul McKinney, Pablo Neira, Julia LaWall, Rik van Riel, Luis R. Rodriguez, Josh Triplett, and Peter Waskiewicz Jr.

The OPW application period for the December 2014 to March 2015 internships closed on Friday, Oct 31.  The Linux kernel continues to be the most popular project in OPW:

  • 24 people applied for an internship and got at least one patch into the Staging tree
  • 551 staging cleanup patches were accepted during the one-month application process
  • 382 files changed, 3464 insertions(+), 4243 deletions(-)

I’m pleased to announce that the following people have been selected for OPW Linux kernel internships from December 2014 to March 2015:

  • Iulia Manda will work with Josh Triplett on kernel tinification.
  • Tina Ruchandan will work with Arnd Bergmann on fixing the kernel subsystems that still have issues with 32-bit timer wrap in 2038.
  • Tapasweni Patha will work with Julia Lawall and Nicolas Palix on using Coccinelle to track the increase of common bug patterns since a whitepaper was published in 2011.
  • Roberta Dobresc will work with Octavian Purdila and Daniel Baluta on migrating Staging IIO drivers to use the kernel’s I/O APIs.
  • Ebru Akagundu will work with Rik van Riel on improving transparent huge page swap performance.

I would like to thank the sponsors for this round: Intel, Codethink, and Samsung.  Without their funding, it would not be possible to pay the OPW interns for their hard work.

The OPW Linux kernel internships have been a great success.  So it is with mixed, bittersweet feelings that I announce I will be stepping down as the coordinator for the Linux kernel OPW internships.  The program is running smoothly, and I find joy every day in watching the OPW Linux kernel interns learn and grow.  However, I am no longer a part of the Linux kernel community.  Julia Lawall, the maintainer of Coccinelle, will be stepping into the role of OPW kernel coordinator.

Fortunately, I’m not leaving the OPW program altogether.  I’ve agreed to step up to help Marina Zhurakhinskaya and Karen Sandler coordinate the larger OPW program, and I will be there to help Julia when she takes over as kernel coordinator in February 2015.

I am proud to have jump-started the effort to make the Linux kernel community more diverse by providing a pipeline for women to get involved in Linux kernel development.  With the help of mentors and sponsors, we’re slowly increasing the diversity of the Linux kernel community.  Four of the eleven OPW interns from the first year the kernel participated in OPW have gotten jobs as Linux kernel developers.

We’re not only improving the community for women developers. We’re helping all newcomers by creating detailed tutorials on how to make your first Linux kernel patch and sharing tips for how to break into open source development culture.  OPW is encouraging Linux kernel developers to think about mentorship and sharing their todo lists, which can only help newcomers find larger kernel projects to tackle. Diversity efforts improve communities for everyone.

Installing Debian on ASUS UX301LA

I ran into some issues with installing Debian on my new Hawell ASUS zenbook laptop. I’m documenting it on my blog to try and ease anyone else’s struggles.

I used the Debian CD image instead of the netinstall. I accidentally installed Debian stable, but later added apt sources to use Debian testing. I used the 20140712 Wheezy amd64 install ISO on a USB 3.0 flash drive.  The drive was plugged into the right side, but I doubt that makes a difference.

Step 1: Reconfigure the BIOS boot options.

Plug in the USB drive, and boot the laptop while pressing F2 to go into the BIOS.  Go into the boot menu, secure boot menu, and disable secure boot.  Go back to the boot menu and enable CSM. Change the boot order so that the USB UEFI boot option is first (before the Windows boot option).  Save, unplug the USB drive, exit BIOS, and boot into Windows.

Step 2: Repartition drives in Windows.

Hit Windows key, type ‘disk’ and click the partitioner.  I had the laptop version with two 256GB drives with software raid, which showed up as a 256GB drive D:/ and a 200GB drive C:/.  I deleted drive D:/, and shrunk drive C:/ as much as the partitioner would allow (which still left 60GB free for Windows to use for my Steam games that don’t have Linux support yet).

Step 3: Go through some of the Debian installer process.

Start the Debian installer. Ignore that it can’t find our network device, pick a host name and add root and normal users.  Choose ‘Manual’ when it comes to partitioning disks.  You’ll see the software raid partition looks like this:

Step 4: Fix the EFI partition.  Select the fat32 EFI system partition, and change ‘Use as’ to ‘EFI boot partition’.

Step 5: Add a new Linux partition.

Choose ‘Automatically partition the free space’ and choose ‘All files in one partition’.  Once the partitions are created, select the ext4 root partition (‘/’) and (optionally) change the mount options to include relatime.  This means that file timestamps aren’t updated automatically, which means less disk writes to the SSDs, thus increasing the lifetime of the disks. If you like, set a label for the root partition so you can see it in Windows later.  After you’re done, the partition disks screen should look like this, and you can hit ‘Finish partitioning and write changes to disk’:

Step 6: Go further in the Debian install process.

Don’t use a network mirror. Pick whether you want to send installed package information to Debian or not. Select Debian desktop and system utilities and continue.

Step 7: Fix grub install failure.

Jamey Sharp figured this out, thanks for his help!  It seems that the standard grub installer was confused by the “Intel Matrix Storage Manager” or IMSM, that’s firmware for booting to RAID setups.  Basically, the BIOS knew about the RAID setup, Linux (mdadm and the kernel) knew about IMSM, but grub didn’t. Grub didn’t know the BIOS used IMSM and could boot from the disk, so grub didn’t think the hard drive was bootable.  Silly grub!

Go to a shell by pressing CTRL+ALT+F2.  Type this command:

df /target

Look at the output of that command.  It will list the file system mount that corresponds to /target (the mount point of the root file system where Debian installs to).  It should look something like /dev/md126p6.  The ‘p6’ is one particular partition on the RAID array, but we want grub to use the whole disk, so we strip off the partition designation for the next couple of commands.  Type this command:

cat > /target/boot/grub/device.map

and then type:

(hd0) /dev/md126

and hit CTRL+d to stop writing to the file.  Then go back to the installer (in the text installer, that’s ATL+F1, but it’s ALT+F5 in the graphical installer).  Hit ‘continue’ and ‘continue’ again to go back to the Debian installer main menu.  Again, hit enter on the ‘Install grub bootloader on the hard disk’.  The installation should complete successfully.

Step 8: Add grub UEFI boot option.

Unplug the USB key, and hit F2 to go back into the BIOS.  The Debian installer didn’t create a UEFI boot option for the grub installation, so we have to make one manually.  Go into the boot menu, and hit ‘Add New Boot Option’ and then ‘Add boot option’.  Pick a name for it (‘GRUB’). Under ‘Path for boot option’, there should only be one choice of filesystem, which starts with PCI. Under ‘Select a file to boot’ choose EFI and then debian and finally grubx64.efi.  Choose ‘Create’ and you’re done adding the boot option.  Hit ‘escape’ to get back to the boot menu.  You’ll need to change the boot option priorities to make grub the first boot option (which means you’ll need to go into the BIOS and change it back should you want to boot into Windows).  Save and exit the BIOS.

Step 9: Update your packages and install Intel wireless firmware.

Debian stable (which is running a 3.2 kernel) will boot into GNOME 3 compatitbility mode because it doesn’t have kernel or mesa support ffor the Haswell Intel graphics.  The kernel also doesn’t recognize the wireless PCI device.  You’ll have to use the USB network adapter and plug into an ethernet cable.

Add the Debian stable sources by editing /etc/apt/sources.list so that it says:

deb http://security.debian.org/ jessie/updates main contrib non-free
deb http://ftp.us.debian.org/debian/ jessie main contrib non-free

You may want to use a different local mirror closer to you.

Run `aptitude` as root, and mark all packages that are upgradable. Mark the firmware-iwlwifi package for installation. And install all your new packages from Debian testing!

After a reboot, both wifi and graphics should be working correctly.

2014 Kernel Internship Report (OPW)

For the past year and a half, the Linux kernel has participated as a project under the FOSS Outreach Program for Women (OPW). OPW provides a three month paid internship for women (cis and trans) and genderqueer or genderfluid people. After a month-long application process, the selected OPW interns are paired with an open source mentor to work on a project. As of August 2014, there are eleven Linux kernel OPW alumni, and five interns that are just finishing up their internships.

The results from the past three OPW rounds are stunning:

  • 1,092 patches accepted into the Linux kernel from OPW alumni and interns
  • Lines of code added and deleted: +32,327, -193,938
  • OPW was a top contributor for the 3.11, 3.12, 3.13, and 3.14 kernels

The sheer number of patches the OPW kernel interns and alumni have created is impressive. They’ve been in the LWN top kernel contributor statistics since the program started in the 3.11 kernel, and they continue to be a top contributor despite the lack of published data for the 3.15 and 3.16 kernels. Making it over the thousand patch mark is a cause to celebrate.  More importantly, the OPW kernel interns and alumni have deleted six times more code than they added. They’re deleting dead code and unused drivers, and thus removing bugs from the Linux kernel.

The statistics from the code development efforts from the OPW kernel interns and alumni are impressive. However, contributing to open source isn’t just about writing code. It’s about interacting on mailing lists, reviewing code, writing documentation, answering questions, working on graphical design, maintaining project websites, and so much more.

The main goal of the OPW internship program is to create a long-term relationship between the mentee, the mentor, and their open source community, in order encourage minorities to continue to contribute to open source. How are we progressing towards the goal of creating more women kernel developers? Are the women who complete OPW kernel internships continuing to work on open source projects after their internship ends? Do they find jobs where they can be paid to work on open source?

In order to measure this, I created a longitudinal study to measure open source contributions of OPW alumni. I’ll send out the survey every 6 to 12 months, and compare the results of the program over time. The most recent survey results from our eleven Linux Kernel OPW alumni shows the program is successful at encouraging women to continue to participate in open source.

Graph of the monthly FOSS contributions from OPW kernel alumni

At least monthly, OPW alumni are engaging and contributing to open source communities. Most of them participate through code submission, testing, and discussion on mailing lists, IRC, or forums. However, it’s interesting to note that a few of the OPW alumni have stepped into open source leadership positions, either by reviewing contributions, maintaining a project, or by managing a team of open source contributors.

Another exciting result of OPW is that some of the kernel OPW alumni are getting paid to work as Linux Kernel developers. Teodora Băluţă is working on Android kernel drivers for Intel’s Open Source Technology Center. Lisa Nguyen is working for Linaro on ARM power management. Lidza Louina is a kernel developer at Oracle.  Xenia Ragiadakou also works on Linux kernel power tuning at OnApp. Elena Ufimtseva isn’t being paid to work on the Linux kernel, but she is working on a proprietary project at Citrix.

I’m overjoyed that these women have found jobs in the technology sector, and so many of them are paid to work as Linux kernel developers. This fact is heartening to me because some of the women that participated in OPW were working in retail before their internship. To be able to move into the technology sector or be hired as a Linux kernel developer is a giant step in the right direction, and I’m happy that the OPW program could be a part of that.

It’s exciting to see five of the eleven OPW kernel alumni get jobs in the technology sector. Four of the kernel OPW kernel alumni are still working their way through Bachelor’s or Master’s degrees. Two OPW kernel alumni are actively looking for jobs. If you need to hire a junior kernel developer, please email the opening to sarah dot a dot sharp at intel dot com, and I will pass the job description onto our OPW alumni.

I will continue to coordinate the Linux kernel mentors and interns under the FOSS Outreach Program for Women (OPW).  The next internship period will run from December 9, 2014 to March 9, 2015.  Applications for the next round open September 8th, and the Linux kernel contributions will be due October 31, 2014.  (Most OPW projects have a deadline of October 22, but the kernel project application process will be on hiatus from October 10 to 20 because many mentors will be attending LinuxCon Europe, Embedded Linux Conference Europe, and Linux Plumbers Conference.  Apply and get your kernel patches in early!)

If you’re interested in applying to be an OPW intern, you can find more information on how to apply on the OPW homepage, and on the OPW kernel project page.  Please note that you do not have to be a student to apply to OPW.  The only requirement is that you’re able to work full-time during the internship period, and that you are a woman (cis or trans), or a genderqueer or genderfluid individual.  This round, we’re also running a pilot to explore opening up the project to other under-represented minorities in tech, by allowing alumni from the Ascend Project to apply.  If the pilot is successful, we’ll be able to expand OPW to encourage chronically underemployed, LGBTQ, Latin@, and African American populations to participate in open source.

[Update 08/26: Fixed this post to note that both Lidza and Xenia are being paid to work as Linux kernel developers.]

Onwards to my next adventure!

I’m joining the Intel OTC ChromeOS differentiation team, and transitioning maintainership of the xHCI driver over to Mathias Nyman.

I’ve only been officially on the team for a couple of weeks, but I’m already playing with webGL tutorials and learning about vertices, shaders, EGL extensions, piglet tests, and loads more about graphics.  It’s been really great working with Josh Triplett and Chad Versace. I managed to join the team in time to attend their group quarterly event at Ground Kontrol.  We played pinball, 80’s games, and DDR for hours. 🙂

Linux Kernel Internships (OPW) Update

A month ago, Amanda McPherson and Greg Kroah-Hartman from the Linux Foundation asked me to coordinate an internship program aimed at getting more women to participate in the Linux kernel. In order to be considered for an internship, the applicants need to submit patches to the Linux kernel, and get them accepted.

The results have been amazing:

  • 41 women applied for 6 Linux kernel internships.
  • In 13 days, 374 patches were submitted, and 137 patches were accepted.
  • Diff stat for accepted patches:
    105 files changed, 3889 insertions(+), 4872 deletions(-)

Continue reading

Reporting Linux Kernel Bugs

Hooray! +Linus Torvalds pulled my first patchset sent directly to him! Usually I send +Greg Kroah-Hartman patches, and he sends a pull request to Linus. It’s a trivial thing, but it means my pull request flow is fine for more than one maintainer. 🙂

ReportingBugs looks much better now, and I hope this rewrite will help explain who to contact about bugs, and what time frame to expect responses back.

Linux Kernel Internships for Women

Want a summer internship working on the Linux kernel?

Internships are available for women and genderqueer/genderfluid people for summer 2013, from June to September. They come with a $5,000 stipend.

We have some pretty awesome projects and helpful mentors, so please apply to the FOSS Outreach for Women (OPW) page.

Please complete your initial application by May 1st. We’re still working on some details, so you’ll be able to update your application until May 17th.

Please share this with any of your friends that might be interested!

Update: If you’re interested in being a mentor for kernel interns in any capacity, or helping review applications or documentations, please let me know. My email is in MAINTAINERS.

The PyCon Incident, Lizard Brains, and Bad Jokes

+Peter Senna Tschudin asked (about the Pycon incident):  “What I can’t understand, and I would like help to understand, is how talking about big dongles to a friend in a conference can become a real problem to a women who is listening. Why did she felt uncomfortable about that? Did she felt threatened? How the dongle size talking could turn into something against her? Can the content of the two guys talking be considered a lack of respect? What are the limits to what can be considered offensive?”

I’m going to take you at face value, and assume you really do want to understand how making simple jokes can cause issues for women in tech.  I’m making this a post, because I think lots of my male friends are worried about cracking jokes right now.

Continue reading