« Mutopia | Home | KMS Font Rendering »
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.
Leave a comment