Posted
about 9 hours
ago
Flyby blog entry. Been an awesome week, hope people enjoyed the Collabora party last night. Getting to the GNOME Shell BOF this morning was a real struggle, but I really like the way its going. We’ve scheduled an Empathy BOF for Friday at 15:45
... [More]
in room 2-4, hoping to talk with folks about improving the accounts UI, tracker/addressbook and GNOME Shell integration.
Aside from that, we’re planning to hack on Empathy for basically the whole day, looking at MC5 porting and UI polish, so there will be a big load of Collabora folks and friends somewhere. Will update when I know where. [Less]
Posted
about 11 hours
ago
Last year, I told you I wanted to use Sieve to filter my mail. I did not switch, because of the lacking implementation of some Sieve features inside Dovecot, my preferred IMAP server.
After that disapointement, I kept my 8 years old mail
... [More]
setup, being fetchmail running on my workstation and throwing the mails in procmail, then using mutt locally to read the maildirs. But that's over.
As I told you yesterday, I got a laptop to replace my workstation. It was not possible to continue using such a mail setup, since my laptop can be offline, and so would be my mails.
So I decided to upgrade Dovecot to 1.2. I used the dovecot-1.2-work Subversion branch of our lovely Debian maintainers, and built a Debian package for Lenny. The upgrade from 1.1 was almost painless, since the configuration file did not change heavily.
Then I started to write my little Sieve script. Sieve is a very nice language. Almost user friendly. So in 20 lines I rewrote all my procmail stuff, matching things like List-Id with regex to put the mails automagically in the right folder. I reconfigured mutt to use IMAP, and it works fine. I even reimported my old Maildir via IMAP using mutt too.
I am now a happy IMAP user.
For people wondering why I wanted to switch away from procmail to Sieve: the reason is that Sieve script can be uploaded remotely via managesieve. This means you do not need FTP/SSH/whatever access to put your script. You can, for example, use connect-sieve or the Sieve plugin for Thunderbird/Icedove. [Less]
Posted
1 day
ago
It’s been about two months since my last update. Most of last month was spent travelling, first to UDS in Barcelona (one of my favorite cities btw), then to London to work at OTC Europe on Moblin, and then on to Oregon to meet with the greater
... [More]
graphics team. In between flights and whenever I had time I also got some good work done; working through PCI patches, improving the error detect/collection code, testing the GPU reset patch a bit more, working on 3D tiling for pre-965 chipsets, and doing general bug fixing. But first things first.
UDS Barcelona
This was the second UDS in Spain I attended (first was in Sevilla a couple of years ago). Overall I found it to be a bit more organized and productive than the first. Probably a sign that the Ubuntu community and Canonical have grown a bit since then…
As I said, I thought this UDS was particularly productive, and ambitious to boot. Scott set an aggressive 10s boot time target for Karmic, and the desktop team decided to pull some very new technologies like KMS and DRI2 into the Karmic release. This is great news for users due to the improved feature set, but also makes life much better for upstream developers, since supporting the new code is much easier than dealing with old DRI1 stuff.
Another huge development (which actually pre-dates this UDS) is the xorg edgers repo. It’s a PPA containing packages of the graphics stack (kernel, libdrm, Mesa, X server and drivers) directly from git. Having this available means testing and development are greatly accelerated; now when users report a bug in the Karmic repos, we can ask them to quickly and easily test the xorg edgers bits to see if their issue has been fixed. If so, we know a backport may be needed, and if not we have a good bug report to feed upstream. I run this repo myself, typically updating every morning, and have found and fixed quite a few bugs as a result of finding them early. Robert and the rest of the edgers team deserve huge thanks from everyone in the Linux community for their work on this repo. I hope their example is followed by other projects, maybe for audio, bluetooth or wireless stacks, which also have large kernel and userland components.
Some other cool stuff got demoed at UDS this time, including some cool Android on Ubuntu work and an Ubuntu spin of Moblin! The latter is especially cool, and I’m hoping to install it on one of my Netbooks soon.
Graphics stuff
The London trip was something of a last minute affair. I was already in Barcelona, and our OTC Europe team in London was in the middle of working on some graphics related Moblin stuff, so they sent Eric, Ian and myself over there to help out. It turned out to be a very productive week; we fixed some major issues while there and overall improved performance by about 50% on some workloads. Some of that work will make its way into our next release and future kernels.
One of the big issues we worked on over there was implementing tiling for 3D textures. We did this awhile ago for some of the major buffers (front, back, depth), but doing it for textures is a bit more involved. Eric quickly got 965+ tiling working, but pre-965 turned out to be a bit more of a pain due to its fencing requirements. The 2D and display engines on pre-965 chips need fence registers to cover tiled regions in order to blit or scan them out. The 3D engine can handle tiled surfaces directly, without fences. The current execbuffer code (the central command submission mechanism) will always allocate fence registers for tiled surfaces however, and on chips with only 8 fence regs (915 and prior) that can be a problem. Not only are fence registers scarce, but mapping and unmapping objects with them can be an expensive operation. So I came up with the execbuffer2 interface, which adds a new relocation type to handle the fence register requirement. Commands using 2D blits for example can use a reloc type that indicates a fence register is required, while purely 3D commands can avoid it. There’s potential for more improvement if we remove 2D blits from the DRI driver, though that may involve more overhead than we’d like, due to the higher setup costs. As it stands, tiling textures can give us a ~20% performance boost on some workloads…
Another thing I had some time to work on at UDS and in London was GPU error handling. Our GPUs have some error handling capabilities we haven’t really taken advantage of until recently. Eric and Carl recently improved the GPU dumping utility significantly, which really makes GPU hang debugging possible. To make things even easier, I put together a patch to use the GPU error interrupt to trigger a error state capture and generate a uevent. The idea here is to capture the error state from the first error, then tell userspace it should capture a full ring & batch buffer dump as soon as possible. This should allow for automated reporting, ala kerneloops, of GPU related errors. The second part of the work involves automatically resetting the GPU when a hang is detected. I posted working patch for that aspect of error handling, but it still needs a little work on the hang detection side before we can push it upstream. I’m hoping both that and the execbuffer2 stuff will land in 2.6.32 (since it’s a bit late for big stuff to land in 2.6.31); the reset patch should be fairly easy to backport though.
Oh yeah, BUGS! The past couple of months have seen unprecedented bug fixing activity on the Intel graphics stack. The removal of the DRI1, XAA, EXA and much of the non-memory manager code is really started to pay off. We’ve been fixing bugs left and right lately, really stabilizing the drivers in both KMS and non-KMS configurations. Not having to worry as much about breaking some weird configuration possibility is a big help (though the non-DRM case still bites us from time to time). In short, things are really looking good on the graphics front these days; the major architectural changes are complete now, and we can really focus on making things solid.
PCI queue
And on the belated “what’s up with PCI this cycle” front, we had one major issue this time around. In an effort to keep the kernel from using BIOS reserved areas, we started using the ACPI _CRS (current resource settings) data from root bridges at boot time, to describe the set of resources on the root bus. Turns out some BIOSes list a ton of resources in _CRS, including legacy VGA and I/O port space. This can be helpful (since the alternative is having a huge list of chipsets and what ranges they’re hardcoded or programmed to decode), but the PCI layer isn’t quite ready to handle arbitrary numbers of bus resource ranges and types. So early in the cycle Linus had to revert the move to using _CRS by default; that said we did get some good fixes from Gary and Yinghai for the _CRS case, so eventually we should be able to use that data in some form.
Of course, eventually I’m hoping to add something like TJ’s resource management code to Linux. Unfortunately TJ seems to have disappeared, and he never did post his code. Fortunately he did leave a good set of notes on his website about what he’d discovered (e.g. which bits of info are reliable and how other OSes use ACPI data etc). The hard part is finding time to implement such a large change and get it tested well enough to feed upstream. The other perennial topic is VGA arbitration. Tiago recently updated his patchset for that, but I haven’t seen it formally submitted to the linux-pci mailing list yet… [Less]
Posted
1 day
ago
After some though, I decided to switch from my big dual screen workstation (called abydos) to a laptop system. I used this workstation for more than 8 years now (with 2 massive hardware changes) on a desk. But my flat not being that big (you know
... [More]
, Paris, it's expensive to rent), I decided to remove my desktop in favor of my guitar setup. Anyway, doing geek stuff all the day at work, I was not sitting at my desk very often.
I've bought a Lenovo Ideapad U330, which is a really nice machine. It's not like a real ThinkPad (ThinkPad are more expensive) but it's still very nice. It has almost everything a good laptop would have, dual core, 4 GB RAM, 320 GB hard drive, WiFi up to 802.11n, DVD writer, webcam, HDMI, etc. And a not-too-small-not-too-big 13.3" LCD display. It's quite light with only 1.9 Kg, but IMHO, I still think it's a bit heavy. YMMV.
I've installed Debian on it (of course) and everything works like a charm. There's only a little bug with the webcam, since the image is upside down. But I'm pretty sure this is already fixed in kernel > 2.6.30. It has been named keller (Stargate fans will know why).
For now I really recommend this laptop. [Less]
Posted
1 day
ago
I happen to have a small side project over here that's a non-conformant, itty-bitty EGL loader for the DRI drivers. Eagle started as a test case for the dri driver interface changes I was doing for DRI2. Before the interface changes, the driver
... [More]
interface was GLX specific and I wanted to remove all X/GLX dependencies from the driver and make it easy to load the dri driver in an EGL framework. So eagle started as a simple loader for the driver to verify the interface changes. At some point I realized that it was pretty close to working and finished up the remaining pieces. It's still lacking a proper EGLConfig picker, but it's fairly capable and sufficient for Wayland.
Now, there's also a mesa EGL loader. The mesa code is very generic and supports EGL on GLX, EGL on gallium, EGL on swrast, whereas Eagle is strictly written to just support the new DRI driver interface. That means Eagle is very minimal, while mesa egl has some overhead (more indirection, more .so's to dlopen). The mesa EGL code doesn't have support for the new (DRI2) dri driver interface, so it only works for gallium capable drivers, specifically, it won't work for the Intel DRI driver.
Merging the Eagle code into the mesa EGL code, has a good number of benefits: the mesa code will learn how to load DRI2 drivers, I won't have to write an fbconfig chooser, and there'll be only one EGL for mesa. So there's a lot of appeal there. The downside, and the main reason I'm still keeping Eagle a separate project is that I want to experiment with the glue code API between EGL and GEM/DRM. The way you create an EGLDisplay or an EGLSurface you have to first somehow create an instance of an EGLNativeDisplayType or EGLNativeWindowType, EGLNativePixmapType and then pass that to an EGL constructor such as eglCreateWindowSurface(). I'm not a diplomat, so let me just say it as it is: that's fricking braindead! See, if you have to go outside the generic EGL API to create an EGLNativePixmapType, why can't we just skip the middle man and create the EGLSurface straight from the implementation specific code. That way we wouldn't have to pollute the EGL API with strange, useless "native" types and we wouldn't need and window and a pixmap constructor for EGL surfaces.
Anyway, the native type fiasco is just a wart in the API that I like obsessing over. There's nothing that prevents an EGL implementation, such as Eagle, from implementing it's own non-standard entry points to create an EGLSurface straight from a GEM buffer handle, for example. Or non-standard API to get at the GEM handle for the back buffer so that we can use the KMS page flipping API. Which is what Eagle does and it's the main reason that it still exists. Eagle is currently a playground where I can try out different types of constructors and extensions for integrating EGL with GEM and KMS. Once we get the KMS page flipping ioctl worked out, I'm planning to write a Eagle+KMS backend for clutter, so clutter apps can run straight on the KMS framebuffer. Next step from there would be a clutter based Wayland compositor... oh wait, isn't that what Moblin should be? [Less]
interface gui xwindows linux xserver x11 graphics unix x x-windows ui freedesktop.org
|
edit tags
