Virtuous blogs jbarnes' braindump


English (US)   Waiting for vblank...  -  Categories: News  -  @ 01:29:11 pm

Will the vblank-rework branch ever be ready to merge upstream? With some recent work by Michel and myself, I really hope so.

It’s a little distressing that such a simple thing could cause so much trouble. The motivation for reworking vblank in the DRM branch was easy enough: save CPU power by turning off interrupts when possible. Not interrupting the CPU lets it sleep deeper and longer, potentially saving quite a bit of power. Getting rid of the 60 or so vertical blank event interrupts per second when they weren’t needed seemed like a logical first step, and so vblank-rework was born.

Being a good citizen in Linux land often means improving whole subsystems rather than stuffing a bunch of fancy features into individual drivers. Working that way can be harder, but it spreads the benefits wider, and improves Linux as a whole. So my efforts in the vblank-rework branch targetting the generic DRM vblank code, improving the driver APIs and making sure that all drivers could benefit from the new infrastructure, allowing them to disable interrupts when not needed. However, that’s where the “harder” part comes in: every driver needed an update. At first I thought, “Hey this is a neat, new set of APIs, surely everyone will want to use them, I’ll just convert the i915 driver (after some initial work on a radeon based laptop).". Unfortunately, the DRM drivers are in dire need of attention, so after several months of waiting I ended up converting all the drivers myself, though only a few like radeon and i915 actually implement the API fully enough to disable interrupts.

So far, so good. I figured everything was fine and the shiny new branch was ready, so I merged it into the master DRM branch in preparation for an upstream push. Then tragedy struck: Michel’s sharp eyes and testing discovered a potentially fatal bug. While many GPUs provide a frame count register we can use to keep the vblank count accurate (necessary since OpenGL extensions expose an absolute count to applications for some reason), they’re typically only updated at the leading edge of vactive. This means that your application may wakeup at vactive time instead of vblank time, causing ugly tearing; exactly what you’d like to avoid! After a bit of back and forth and a couple of false starts (trying to work around the problem with solutions that turned out to be racy), we decided to go back to using the atomic counter (which is only updated at interrupt time) for wakeups, rather than the hw register, using the latter for keeping the counter accurate across interrupt disable periods.

Which brings us to last week. I hacked up the scheme described above and started testing. As I found and fixed bugs (well actually Michel probably found most of them), I discovered that the API could actually be simplified a bit, and some of the code to compensate for corner cases was no longer necessary, so both the wraparound compensation logic in the pre/post modeset ioctl and the funky accounting we tried to do there could be removed. The result, I hope, is ready for upstream finally.

So where does that leave us, API-wise? Well, on the userland front we have a new ioctl, DRM_IOCTL_MODESET_CTL, with _DRM_PRE_MODESET and _DRM_POST_MODESET arguments. It should be called with _DRM_PRE_MODESET in userland drivers prior to any activity that resets the hw frame counter (typically mode setting). When the mode set completes, it should be called again with _DRM_POST_MODESET. These calls tell the kernel to account for any lost events so that the vblank count exposed to applications can stay accurate.

On the driver front, there are a few different calls and callbacks:

With a few simple changes, a given DRM driver can support the new scheme to save power. If you find bugs or have issues with the new APIs, let me know and/or file a bug at


English (US)   Prepping the PCI tree  -  Categories: News  -  @ 08:03:30 pm

Figured I’d give an overview of the latest PCI stuff for those of you that don’t drink from the lkml firehose.

The PCI linux-next branch was a bit more exciting than I expected it to be. We’ve got lots of good changes queued up. Some of the highlights:

There’s also an assortment of fixes here; hopefully we haven’t broken anything too badly…

The bottom line is this though: if you’ve been hesitant to try suspend/resume with Linux, or have had bad wake-on-lan or other wakeup event experiences, or you use PCI hotplug at all, this is a good release for you to try. You can report bugs to, and/or and we’ll take a look!


English (US)   Fun in Folsom  -  Categories: News  -  @ 10:44:20 pm

Just got back from a nice dinner & “gelato” (it was really ice cream) with Keith & Nanhai. We went to the Cliff House here in Folsom; we all ended up getting tasty steaks.

But back to the matter at hand. We’re all here at GfxCon 2008, an Intel event that brings together graphics architects and developers from across the company. There’s a lot of fun stuff going on, with some good sessions today and interesting demos (though of course I can’t talk about any of them, you’ll just have to wait for the products!).

The best part though has been the networking. It’s great to meet the developers I’ve only worked with over email, and have discussions face to face. Keith and I had some good brainstorming sessions about how to handle hardware contexts, and how we want to deal with vblank syncing in the GEM-enabled world. Fortunately, our discussions ended up sounding very similar to the discussions I had with krh back at XDC about vblank syncing in DRI2. Now I just have to code it up…

Hm, and let’s see how I’ve done keeping my promises from last week:

Hopefully I’ll be able to find time tomorrow with Nanhai or Keith to review and push some of the stuff above… Then on to hardware contexts.


English (US)    -  Categories: News  -  @ 07:36:01 pm

Ok, so I have a blog. The *intent* here is to post frequently about my various Linux & gfx related activities, but note that intent doesn’t always become reality…

powered by b2evolution free blog software

Contact the admin - Credits: multiblog | green power hosting | test