August 2009 Archives
August 25, 2009
KMS Font Rendering
Font rendering now works with the KMS Glamo driver. The problem was that a particular case of the trickiest EXA function ("ModifyPixmapHeader") wasn't handled correctly. The easy fix was to remove our implementation of that hook altogether and let EXA handle it on its own. To make this work properly, a new function (with similar but more limited functionality) had to be added to deal with the initialisation of the front buffer, like this.
So now, apart from whatever gremlins might be lurking deep in the code, the KMS driver should be on an even footing with the non-KMS version. Before getting on with Mesa and other such fun stuff, I'd still like to get to the bottom of the GEM hashtable corruption that seems to happen after a long time (more than a day) of operation. Additionally, there's a small issue with the width of the screen that happens with recent versions of X.org (1.6.1 and later at the very least), but that isn't specific to KMS.
For an up-to-date list of "things that are bothering me" like these, see this new page. Call it an unofficial project status page.
So now, apart from whatever gremlins might be lurking deep in the code, the KMS driver should be on an even footing with the non-KMS version. Before getting on with Mesa and other such fun stuff, I'd still like to get to the bottom of the GEM hashtable corruption that seems to happen after a long time (more than a day) of operation. Additionally, there's a small issue with the width of the screen that happens with recent versions of X.org (1.6.1 and later at the very least), but that isn't specific to KMS.
For an up-to-date list of "things that are bothering me" like these, see this new page. Call it an unofficial project status page.
August 20, 2009
KMS Progress, and Publicity
Listen to the sound of silence..
... that's the silence of intense concentration as things get exciting in the land of Glamo-DRI ...
Some welcome publicity (see Phoronix and Timo Jyrinki's Blog) has led to a burst of activity from me. It really does make a difference to know that people are interested in and excited by the project.
The current status is that the KMS Xorg driver is vaguely usable, apart from garbled font rendering and an occasional kernel oops. I'm tracking these down at the moment. A busy-wait is currently being used for synchronisation in the kernel, which isn't great (but no worse than the current system). This will get turned into a much more advanced interrupt-driver waitqueue system once I've worked the details out.
It turns out that the overheads involved with mmapping a pixmap's corresponding GEM object (every time X wants to draw something to it) have a fairly significant impact. X appears to be quite bad at batching operations together in a single period of access. Additionally, even tiny scratch pixmaps (which we have no hope of meaningfully accelerating) end up getting GEM objects as well. Optimisations are possible - we can leave each object mapped, and give the address back fast to X when it requests access. This is what the Radeon driver does in recent versions. Additionally, the latest Git version of the X.org server includes something called mixed mode pixmap handling, which is where EXA keeps the clearly unacceleratable pixmaps away from the driver and in the much faster system memory. The latter brings the speed almost up to what it was pre-KMS. I need to do some more experiments with the former.
... that's the silence of intense concentration as things get exciting in the land of Glamo-DRI ...
Some welcome publicity (see Phoronix and Timo Jyrinki's Blog) has led to a burst of activity from me. It really does make a difference to know that people are interested in and excited by the project.
The current status is that the KMS Xorg driver is vaguely usable, apart from garbled font rendering and an occasional kernel oops. I'm tracking these down at the moment. A busy-wait is currently being used for synchronisation in the kernel, which isn't great (but no worse than the current system). This will get turned into a much more advanced interrupt-driver waitqueue system once I've worked the details out.
It turns out that the overheads involved with mmapping a pixmap's corresponding GEM object (every time X wants to draw something to it) have a fairly significant impact. X appears to be quite bad at batching operations together in a single period of access. Additionally, even tiny scratch pixmaps (which we have no hope of meaningfully accelerating) end up getting GEM objects as well. Optimisations are possible - we can leave each object mapped, and give the address back fast to X when it requests access. This is what the Radeon driver does in recent versions. Additionally, the latest Git version of the X.org server includes something called mixed mode pixmap handling, which is where EXA keeps the clearly unacceleratable pixmaps away from the driver and in the much faster system memory. The latter brings the speed almost up to what it was pre-KMS. I need to do some more experiments with the former.
August 14, 2009
Mutopia
I've recently discovered the Mutopia Project, which is about producing Free (mostly Creative Commons) sheet music, mostly typeset using the LilyPond software, which I've also only just discovered.
One of my favourites is the 16th Fugue from Das Wohltemperierte Clavier (The Well-Tempered Piano) by Bach. One of the first sounds I ever heard coming out of a computer was this, played by a program called Maestro using a fairly hideously synthesised sound effect on an Acorn A3000 in about 1990.
There is also the Passacaglia, which the attentive reader of this site will recognise. Not that there are any.
It almost makes me want to take up music again (playing it, that is). But on my own terms, rather than following a strict grading scheme. It's the difference between doing something because you want to, and doing it because your teacher told you to.
One of my favourites is the 16th Fugue from Das Wohltemperierte Clavier (The Well-Tempered Piano) by Bach. One of the first sounds I ever heard coming out of a computer was this, played by a program called Maestro using a fairly hideously synthesised sound effect on an Acorn A3000 in about 1990.
There is also the Passacaglia, which the attentive reader of this site will recognise. Not that there are any.
It almost makes me want to take up music again (playing it, that is). But on my own terms, rather than following a strict grading scheme. It's the difference between doing something because you want to, and doing it because your teacher told you to.
August 4, 2009
KMS X.Org Driver - Almost
The lack of posting on this subject recently has simply been because
I've, erm, been coding too hard. Here's a picture of the latest
situation: An X.Org driver running on a Neo FreeRunner, plus or minus a few "issues" which need ironing out:
One of the more interesting parts of the recent hackathon has been the way GEM objects, held in Glamo's VRAM, are mapped into the address space of a process. In this way, a process can access something - such as an offscreen pixmap, the overall X framebuffer or later something such as a vertex list or texture object - in an unaccelerated fashion. Unaccelerated accesses have to happen at some point (we have to get data into Glamo at some point before more exciting accelerated things can be done with that data), so this isn't a bad thing and is quite important in the grand scheme of things. The way it works has a few steps:
One of the more interesting parts of the recent hackathon has been the way GEM objects, held in Glamo's VRAM, are mapped into the address space of a process. In this way, a process can access something - such as an offscreen pixmap, the overall X framebuffer or later something such as a vertex list or texture object - in an unaccelerated fashion. Unaccelerated accesses have to happen at some point (we have to get data into Glamo at some point before more exciting accelerated things can be done with that data), so this isn't a bad thing and is quite important in the grand scheme of things. The way it works has a few steps:- The process calls our ioctl, DRM_IOCTL_GLAMO_GEM_MMAP, passing the handle of the GEM object it's interested in mapping.
- The kernel generates an offset, and records it in a list next to the GEM handle. The DRM device, /dev/dri/card0, behaves as if it were a huge file, sections of which correspond to GEM objects that have been mapped. The offset gets returned to the process.
- The process calls mmap() with its file descriptor (corresponding to /dev/dri/card0), the offset and size of the object.
- The core bits of kernel generate a new virtual memory area (VMA) for the newly mmap'd area, and pass control to DRM.
- DRM looks up the offset in its list, and - if found - sets up some flags on the VMA. Notice that nothing has actually used the true physical memory address of the VRAM yet.
- The kernel returns the start address of the new VMA to the process, which tries to access its contents.
- The access to the memory generates a page fault, which gets passed back through the kernel and eventually ends up in our DRM driver. Finally, we set up the page tables so that the virtual address given to the process actually corresponds to the VRAM inside Glamo.
