fidzu : freedesktop

Make of them what you will.

daniels@psyence:~/x/xorg/xserver% wc -l **/*.[ch] | tail -1
730420 total
daniels@psyence:~/x/xorg/xserver% git diff -p xorg-server-0_99_1.. | diffstat | tail -1
2747 files changed, 178062 insertions(+), 628051 deletions(-)
daniels@psyence:~/x/xorg/xserver% echo $((628051-178062))
449989

24 Jul 2008 12:15am GMT

I rarely blog these days, doing the Twitter thing instead and all. Anyway. The Call for Papers for the Linux Plumbers Conference in September in lovely Portland, Oregon has been extended until July 31st 2008. It's a conference about the core infrastructure of Linux systems: the part of the system where userspace and the kernel interface. It's the first conference where the focus is specifically on getting together the kernel people who work on the userspace interfaces and the userspace people who have to deal with kernel interfaces. It's supposed to be a place where all the people doing infrastructure work sit down and talk, so that each other understands better what the requirements and needs of the other are, and where we can work towards fixing the major problems we currently have with our lower-level APIs.

I'm running the "Desktop Integration" microconf at Plumbers. I have two goals for the microconf. One is to be informative about what's going on in the dusty hallways between the Kernel and the Free Desktop. Which I think is important at a place like Plumbers where we're going to a lot of people working on similar problems present. The other goal is to actually try and make some headway on actual problems that require people from multiple communities working together. Such as some of the work Jon is focusing on, e.g. how to make fast-user-switching, multi-seat and terminal services Just Work(tm).

The conference is expected to sell out pretty quickly so it's a good idea to go ahead and register for Plumbers Conference instead of procrastinating about doing it!

See you in Portland!

23 Jul 2008 5:46pm GMT

The Fedora 10 name elections are open. My totally awesome name suggestion for F9 (Bathysphere) lost by a slim margin, so now I'm lobbying harder for decent names. So here's what you should vote for:

• Whiskey Run, because whiskey is awesome, and the potential for a whiskeyrunner theme in the artwork is excellent.
• 
  
• Saltpetre, because it's a double-whammy connection with Sulphur (British variant spelling, and component of gunpowder), and gunpowder -> steampunk art -> awesome.
• 
  
• Farnsworth, because Futurama.
• 
  
• Cambridge, because Red Hat Linux 10 would have been Cambridge, and we finally made it to version 10 of something.

Every time you vote for something else, God detonates a kitten.

23 Jul 2008 2:34pm GMT

The Call for Papers for the Linux Plumbers Conference in September in Portland, Oregon has been extended until July 31st 2008. It's a conference about the core infrastructure of Linux systems: the part of the system where userspace and the kernel interface. It's the first conference where the focus is specifically on getting together the kernel people who work on the userspace interfaces and the userspace people who have to deal with kernel interfaces. It's supposed to be a place where all the people doing infrastructure work sit down and talk, so that each other understands better what the requirements and needs of the other are, and where we can work towards fixing the major problems we currently have with our lower-level APIs.

I am running the Audio microconf of the Plumbers Conference. Audio infrastructure on Linux is still heavily fragmented. Pro, desktop and embedded worlds are almost completely seperate worlds. While we have quite good driver support the user experience is far from perfect, mostly due because our infrastructure is so balkanized. Join us at the Plumbers Conference and help to fix this! If you are doing audio infrastructure work on Linux, make sure to attend and submit a paper!

Sign up soon! Send in your paper early! The conference is expected to sell out pretty quickly!

See you in Portland!

23 Jul 2008 11:39am GMT

Back in the day, I used my paycheck to buy the top-notch MP3 player that was the Rio500. Unfortunately, I forgot it in the back pocket on my plane seat when flying over to Raleigh for my Red Hat induction. And then I used one of my first new job paycheck to buy a second generation (and very very expensive) iPod.

You could say that hacking on Walk500, a front-end to that great player is the reason why I'm hacking on GNOME these days.


I couldn't bear the thought anymore, and bought a Rio500 on eBay for $5. Hacking on it half-an-hour at a time, I cleaned up the code. The latest release of the modern era is available on SourceForge.

23 Jul 2008 10:01am GMT

If the doctor is content with the situation the metal in my finger is removed today. Then I'll be able to type normally again, yippee! Ok, after some painful weeks stretching and strengthening the muscles... ;-)

Wish me luck.

23 Jul 2008 9:57am GMT

Don't know anymore how I landed on Five Geek Social Fallacies but I was feeling good about myself not feeling very afflicted with any of them. That is, until I hit number 5.

Yes, I admit to having bouts of 'oh-you-didn't-invite-me-what's-wrong-with-us', and its inverse, 'oh-my-god-there-are-not-enough-chairs-for-all-the-people-I-should-be-inviting-I-will-end-up-on-a-lot-of-no-invite-lists'.

If you saw me in either mode at some point in life feel free to let me know if you notice any improvement at all on this front.

22 Jul 2008 9:17pm GMT

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:

• drm_vblank_get - increase the refcount on the vblank counter

  This call just tells the core code that the caller is actively using the vblank counter for something, e.g. scheduled buffer swaps or a blocking vblank wait call.

• drm_vblank_put - decrease the refcount

  Tell the core you're done with the vblank counter. When the refcount reaches 0, the kernel knows it can disable the interrupt at some point in the future.

• drm_vblank_init - initialize the core vblank code

  Should be called at driver load time or IRQ init ioctl time to init the core.

• driver.get_vblank_counter - return the current hw frame count

  Used by the core code to keep the count accurate across interrupt enable/disable periods.

• driver.enable_vblank - enable vblank interrupts on a given CRTC

  Used by the core to enable interrupts when the refcount increases.

• driver.disable_vblank - disable vblank interrupts on a given CRTC

  Used by the core to disable interrupts after a timeout period if the refcount is 0.

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 bugs.freedesktop.org.

22 Jul 2008 7:29pm GMT

I guess I must be awesomely famous or something (probably "or something"). My new job has already been mentioned on Phoronix.com. Unfortunately, the work that I will be doing to parallelize Mesa won't be for anything as glamorous as Larrabee.

In fact, it will be for the complete opposite end of the spectrum. We're seeing more and more chips, like Intel's own Atom, that trade wide, out-of-order pipelines for simpler, in-order cores with multiple threads per core. On those types of architectures, especially when hardware TNL is not available, Mesa's performance is really, really bad.

There is room for a lot of improvement even on more traditional systems with hardware TNL and processors with good single-threaded performance. It is easy to find apps where lot of time is spent in the app, a lot of time is spent in the driver, and only one CPU is utilized. Sure, the app developer could multi-thread the app, but why? That means multi-threaded optimization needs to be done in N places (for N apps) instead of just one.

Anyway...I guess I should get back to work now...

22 Jul 2008 7:15pm GMT

We arrive in Hong Kong about a day ago, after a insanely long flight. I don't know whether it's just Air New Zealand who provides all of 4" of leg room on Economy flights, or all airlines... It really sucks. I feel sorry for those who were continuing on to London Heathrow without any break.

I didn't manage to sleep on the flight so I was only barely awake during the morning, but we still had a good look around some of the shops and malls. We didn't have time to buy anything yet; the place is massive.

I'll post some photos later tonight, or if not, they will be on Steve's Live Journal: http://dragonflamezor.livejournal.com/

22 Jul 2008 2:22pm GMT

when after 10 minutes of brushing your teeth and waiting for the short judder to indicate that you can stop brushing, you realize you're not actually holding an electric toothbrush.

I guess I don't need to brush my teeth for the next 3 days.

22 Jul 2008 9:32am GMT

Ok, so I didn't get a lot of time for coding last week. And, this week there's OSCON, so coding time will be short again. I figured I should spend some time writing up a brief report about where X output is at today.

Output Hotplug

I think this stuff is fairly solid these days, although we don't have much in the way of auto-detection of monitor connect/disconnect. There are two reasons here:

1. The hardware notifies the operating system via an interrupt. Given mode setting code in user space, dealing with interrupts is a huge pain and hence hasn't been hooked up yet (see below).

2. Analog outputs (VGA, TV) do detection using impedance changes in the output signal path. This means we have to keep them active if we want to detect a connection. That takes a lot of power (about 1W to light up the VGA output without a monitor connected). What we could do is detect when a monitor was unplugged; that's free.

There are a few other random improvements that are coming soon, like CEA additions to the EDID parsing code. These are additional data blocks that follow the standard EDID data and are used for 'consumer electronics' devices. Supporting these should make more HDMI monitors 'just work'.

Initial Mode Selection

Detecting connected monitors is fine, but one thing we haven't really solved is what to do when you have more than one connected when the server starts. My initial code would pick one 'primary' monitor, light that up at its preferred size and then pick modes for the other monitors which were as close as possible to the primary monitor size without being larger. Obviously, I liked that as it meant my laptop always came up looking correct on the LVDS and my external VGA would show most of the screen.

However, this was reported to confuse a lot of users. I can imagine that starting the X server with one of the outputs connected but not turned on would make for some 'interesting' support calls. So, now the X server picks a mode which all outputs can support and uses that everywhere. Sadly, this means that my laptop panel gets some random scaled mode (usually 1024x768) which looks quite awful.

I think we need something better than either of these choices, but I'm not quite sure how it should work.

Kernel Mode Setting

A bunch of people, including Jesse Barnes and Dave Airlie, have been hacking to move the output configuration code into the kernel. This will solve lots of little problems, like how to display kernel panic messages, and how to deal with interrupts for output hotplug.

This code is up and running fairly well these days, but depends on a kernel memory manager to deal with frame buffers. The integration of GEM into the kernel is blocking this work, but I'm hopeful that this will be sorted out in the next couple of weeks.

GEM - the Graphics Execution Manager

Work here was stalled for a few weeks while we sorted out memory channel interleaving issues. Now things are moving again, and we're working on getting it stable enough to merge into master. That means fixing a few more critical bugs that the Intel QA team has identified.

One of these bugs is that our GL conformance tests weren't working right; that turned out to be caused by tests reading back data from the frame buffer one pixel at a time. Our read-back path passed through the GEM memory domain code to pull objects back from GTT space to CPU space. That meant flushing the front, back and depth buffers from the CPU cache. With each of those at 16MB, reading a single pixel took long enough that the tests would time-out. Increasing the timeouts to 'way too long' is making them run, but tests which would complete in a few hours are now taking days.

We've got two different plans for fixing the read-back path:

1. Use pread to access precisely the data we need. This would involve flushing a single cache line for the tests above.

2. Mapping the back buffer through the GTT. This would eliminate the need to clflush anything as the GTT mappings are write combining and so reads bypass the cache.

Eric is working on the former, and I'm working on the latter. More news later (this week?) when we see which one wins.

Composite Acceleration

With Owen Taylor's change to the glyph management code in the server, Eric and Carl were able to change the driver to batch multiple glyph drawing operations into a command buffer. Once Carl had this working, we went from 13000 glyphs/sec to 103000 glyphs/sec. Obviously we're hoping for even larger improvements as a pure software solution is well over 1 million glyphs/sec. Even still, 103000 glyphs/sec is enough to make my desktop vastly more usable, and using the software path means losing a lot of other useful acceleration.

DRI2 - Redirected Direct Rendering

Right now, direct rendered GL applications (which is the fastest way we can do GL at present) get drawn to a giant screen-sized back buffer and then copied from there to the screen at swap buffers time. Because everyone shares the same back buffer, you get to clip your drawing as if you were drawing directly to the screen. While this normally doesn't matter much (aside from some performance costs associated with lots of clip rectangles), when you're running a compositing manager (like compiz), the 3D applications end up ignoring the per-window offscreen pixmap and spam their output directly to the real frame buffer.

DRI2, written by Kristen Høgsberg, solves this by changing how direct rendering works and giving everyone a private back-buffer to draw to. Now, at buffer swap time, that private back-buffer can be copied to the window's pixmap and compiz is happy.

This work has been around for a few months, but depends on a TTM-based memory manager. That dependency isn't very strong, and krh has promised to fix it shortly. Once that's done, getting the GEM driver to support DRI2 won't take long, and we'll have our fully composited desktop running. With luck, that'll happen before September.

Final Words

As you can see, we're nearing the end of our long X output rework saga, with most of the pieces falling into place in the next month or two.

22 Jul 2008 1:25am GMT

Okay, it's been a week already, but it was not only the back from GUADEC for me, but coming back to Dublin at the Sun offices as a full time employee.

GUADEC has been great time, as usual, I would like to thanks Baris and the whole Istanbul team for their excellent job.

Others have summarized the contents pretty well, so I won't go through that. However, which is been pretty clear to me is that this GUADEC has been an interesting start point towards leadership strength on the community.

• First, Stormy Peters as our Executive Director, this is probably the best decision that the board has made since I've got involved in GNOME, I'm pretty sure she's going to make a difference in the project's direction and focus, plus getting in touch with other parties to make them embrace our community and technology more and better than before. Go Stormy!
• Second, Gtk+ 3.0, okay, a lot of people have complained about certain details about the plan, however, we have a plan that can be discussed, and we have people committed to accomplish it, that is way far better than no having plan and no people at all. Big kudos to the Imendio guys and other Gtk+ heads for pushing this discussion further.
• And third, the GNOME release team for putting the 3.0 release with a better long term strategy for the desktop in the table. Again another leadership show that I highly appreciate.

My talks went pretty well, however, the attendance to both the APOC and the Gtk+ one were pretty low since unfortunately both of them were on the after hours track. It was specially sad that no core Gtk+ hackers were around for the last one, I might extend the topic a little further and even propose a keynote next year as suggested by some Igalians (which were pretty much the 90% of the audience :-( ).

And last but not least, the board have decided to go for Gran Canaria as next years' GUADEC, I'm pretty thankful to the board for trusting our proposal and I'll make sure that next year is at least as good as the previous ones. If you have any suggestions, feedback or if you want to volunteer for helping, don't hesitate to give us a shout at the guadec's mailing list.

21 Jul 2008 12:12pm GMT

Regarding recent discussions related to (D)VCS for GNOME, I think people might fight interesting results of the voting on highly popular Russian Linux site (analog of Slashdot). The comments is all in Russian, but everyone can read and interpret the results… (Just in case you care to follow the link, "Не использую"="Do not use"). May be, staying with the current Subversion is not a bad idea, after all?;)

Yesterday, I reformatted internal n810's flash from FAT32 to ext3. Why? Because root partition is too small and crouded. Now, I have several Megs of canola2 covers, this is too much for my small root…

BTW, I could not find the way to make canola use non-default place for disk covers (and symlinking to FAT32 partitions does not help - there are some issues with Russian dirnames).

21 Jul 2008 9:11am GMT

I reached a nice milestone today: working playback on my Geforce 6200. Most of the work went into the winsys layer, with some bug fixes and workarounds in other places, but everything is up and running now. Unfortunately the output isn't perfect, there is some slight corruption here and there. I'm guessing it has to do with some dodgy assumptions I made about shader arithmetic (rounding, saturation, etc) that SoftPipe went along with but the GPU didn't. The other issue is that there is some severe slowdown when any 2D drawing happens on the rest of the desktop. I'm guessing this may be due locking when copying the backbuffer to the window, or maybe I'm completely soaking up the CPU.

Currently nothing is optimized, I'm not even turning on compiler optimization, and I have a really slow prototype IDCT implementation performed on the CPU in place of the hardware version, so I'm sure I'm eating up a lot more CPU time than I will be by the end of the summer. I have a lot of different ideas on optimization that will target CPU usage and GPU fillrate usage, but given that I get almost full speed playback currently, I'm pretty confident that I'll be able to get HD playback by the end of SoC.

As far as the winsys goes, I was able to use most of the current Nouveau winsys. Unfortunately the DRI stuff is buried within Mesa right now, so I had to extract a lot of things and create a standalone library to handle screens, drawables, the SAREA, etc. to be able to use DRI without including and linking with half of Mesa. The winsys interface is also simpler than Mesa's; there are only a few client calls, the backbuffer is handled in the state tracker, and the winsys doesn't have to create or call into the state tracker. It took me a while to realize why the Mesa winsys was set up the way it was, and that I could simpify things on my end.

Here are some screen grabs:

21 Jul 2008 1:53am GMT

So this weekend was a total technology fail..

so on Sat night Gia rented a DVD to watch on a laptop, I was all should be no problem with this, armed with my livna (and livna-development) repositories, I started off on laptop 1, Thinkpad T60P. totem pulled an immeditate choke with some useless error message. mplayer choked similiarly with a nice bonghits in the libdvdread error message. This I tracked down to the region not being set correctly, so I set the drive region to region 4, and then mplayer failed even harder in a tight loop with kill -9 the only way out. It looked like bad sectors or something in the kernel.

So I went and tried it on laptop number 2, my Dell Insprion 6000, this machine is the oldest piece of kit I own and has been steadily on it way out the door (backlight flickers on/off due to dodgy connections internally). However it is also the only machine I have at home with a non-Linux OS on it, it has Windows XP. So I booted XP on it, stuck the disk in and it played fine, I then booted Linux on it and had the same problem as on the the other laptop. So I decided to let Gia use Windows XP to watch the DVD, I then unplugged the laptop before realising the battery was sitting on the bench (as it overheats a lot instead of charging nowadays.. and it isn't one of the goes on fire batteries either..). So it appears cutting the power wasn't such a good idea, as it appears the hard disk heads crashed or some such fail, as attempting to boot XP on the laptop after that gave a bad boot bluescreen and mounting the XP ntfs partition from Linux went into an ATA reset cycle.

So I had to watch half the rugby (it wasn't a great game in the end), and then watch some movie with Matthew McConaughty in it, at least there was scuba diving in it, so it could have been worse.

Then on Sunday on our way to the cinema, I drops my iphones on the grounds. Oh noes. My iphone volume buttons have been busted for a month or two in any case, but now the lock/power button decided to stop being useful. Of course my iphone is a US phone where I'm sure the warranty has been invalidated six ways from Tuesday at this point. So I'll probably have to go opens it ups and play with its insides. I've damaged a lot of phones in my life but the iphone has actually been the quickest to get broken, and considering I don't drink nearly as much as I used to this isn't a good showing for it.

20 Jul 2008 11:14pm GMT