Reworking Intel Glamor
The original Intel driver Glamor support was based on the notion that
it would be better to have the Intel driver capture any fall backs and
try to make them faster than Glamor could do internally. Now that
Glamor has reasonably complete acceleration, and its fall backs aren t
terrible, this isn t as useful as it once was, and because this uses
Glamor in a weird way, we re making the Glamor code harder to maintain.
Fixing the Intel driver to
not use Glamor in this way took a bit of
effort; the UXA support is all tied into the overall operation of the
driver.
Separating out UXA functions
The first task was to just identify which functions were UXA-specific
by adding _uxa to their names. A couple dozen sed runs and now a
bunch of the driver is looking better.
Next, a pile of UXA-specific functions were actually inside the
non-UXA parts of the code. Those got moved out, and a new
intel_uxa.h file was created to hold all of the definitions.
Finally, a few non UXA-specific functions were actually in the uxa
files; those got moved over to the generic code.
Removing the Glamor paths in UXA
Each one of the UXA functions had a little piece of code at the top
like:
if (uxa_screen->info->flags & UXA_USE_GLAMOR)
int ok = 0;
if (uxa_prepare_access(pDrawable, UXA_GLAMOR_ACCESS_RW))
ok = glamor_fill_spans_nf(pDrawable,
pGC, n, ppt, pwidth, fSorted);
uxa_finish_access(pDrawable, UXA_GLAMOR_ACCESS_RW);
if (!ok)
goto fallback;
return;
Pulling those out shrank the UXA code by quite a bit.
Selecting Acceleration (or not)
The intel driver only supported UXA before; Glamor was really just a
slightly different mode for UXA. I switched the driver from using a
bit in the UXA flags to having an accel variable which could be one of
three options:
- ACCEL_GLAMOR.
- ACCEL_UXA.
- ACCEL_NONE
I added ACCEL_NONE to give us a dumb frame buffer mode. That actually
supports DRI3 so that we can bring up Mesa and run it under X before
we have any acceleration code ready; avoiding a dependency loop when
doing new hardware. All that it requires is a kernel that offers
mode setting and buffer allocation.
Initializing Glamor
With UXA no longer supporting Glamor, it was time to plug the Glamor
support into the top of the driver. That meant changing a bunch of the
entry points to select appropriate Glamor or UXA functionality,
instead of just calling into UXA. So, now we ve got lots of places
that look like:
switch (intel->accel)
#if USE_GLAMOR
case ACCEL_GLAMOR:
if (!intel_glamor_create_screen_resources(screen))
return FALSE;
break;
#endif
#if USE_UXA
case ACCEL_UXA:
if (!intel_uxa_create_screen_resources(screen))
return FALSE;
break;
#endif
case ACCEL_NONE:
if (!intel_none_create_screen_resources(screen))
return FALSE;
break;
Using a switch means that we can easily elide code that isn t wanted
in a particular build. Of course accel is an enum, so places which
are missing one of the required paths will cause a compiler warning.
It s not all perfectly clean yet; there are piles of UXA-only paths
still.
Making It Build Without UXA
The final trick was to make the driver build without UXA turned on;
that took several iterations before I had the symbols sorted out
appropriately.
I built the driver with various acceleration options and then tried to
count the lines of source code. What I did was just list the source
files named in the driver binary itself. This skips all of the header
files and the render program source code, and ignores the fact that
there are a bunch of #ifdef s in the uxa directory selecting between
uxa, glamor and none.
Accel Lines Size(B)
----------- ------ -------
none 7143 73039
glamor 7397 76540
uxa 25979 283777
sna 118832 1303904
none legacy 14449 152480
glamor legacy 14703 156125
uxa legacy 33285 350685
sna legacy 126138 1395231
The legacy addition supports i810-class hardware, which is needed
for a complete driver.
Along The Way, Enable Tiling for the Front Buffer
While hacking the code, I discovered that the initial frame buffer
allocated for the screen was created without tiling
because a few
parameters that depend on the GTT size were not initialized until
after that frame buffer was allocated. I haven t analyzed what effect
this has on performance.
Page Flipping and Resize
Page flipping (or just flipping) means switching the entire display
from one frame buffer to another. It s generally the fastest way of
updating the screen as you don t have to copy any bits.
The trick with flipping is that a client hands you a random
pixmap and you need to stuff that into the KMS API. With UXA, that s
pretty easy as all pixmaps are managed through the UXA API which knows
which underlying kernel BO is tied with each pixmap. Using Glamor,
only the underlying GL driver knows the mapping. Fortunately (?), we
have the EGL Image extension, which lets us take a random GL texture
and turn it into a file descriptor for a DMA-BUF kernel object. So, we
have this cute little dance:
fd = glamor_fd_from_pixmap(screen,
pixmap,
&stride,
&size);
bo = drm_intel_bo_gem_create_from_prime(intel->bufmgr, fd, size);
close(fd);
intel_glamor_get_pixmap(pixmap)->bo = bo;
That last bit remembers the bo in some local memory so we don t have to
do this more than once for each pixmap. glamor
fdfrom
pixmap ends up
calling eglCreateImageKHR followed by gbmbo_import and then a kernel
ioctl to convert a prime handle into an fd. It s all quite
round-about, but it does seem to work just fine.
After I d gotten Glamor mostly working, I tried a few OpenGL
applications and discovered flipping wasn t working. That turned out
to have an unexpected consequence all full-screen applications
would run flat-out, and not be limited to frame rate. Present
recovers from a failed flip queue operation by immediately
performing a CopyArea; not waiting for vblank. This needs to get fixed
in Present by having it re-queued the CopyArea for the right
time. What I did in the intel driver was to add a bunch more checks
for tiling mode, pixmap stride and other things to catch pixmaps that
were going to fail before the operation was queued and forcing them to
fall back to CopyArea at the right time.
The second adventure was with XRandR. Glamor has an API to fix up the
screen pixmap for a new frame buffer, but that pulls the size of the
frame buffer out of the pixmap instead of out of the screen. XRandR
leaves the pixmap size set to the old screen size during this call;
fixing that just meant getting the pixmap size set correctly before
calling into glamor. I think glamor should get fixed to use the screen
size rather than the pixmap size.
Painting Root before Mode set
The X server has generally done initialization in one order:
- Create root pixmap
- Set video modes
- Paint root window
Recently, we ve added a -background none option to the X server
which causes it to set the root window background to none and have the
driver fill in that pixmap with whatever contents were on the screen
before the X server started.
In a pre-Glamor world, that was done by hacking the video driver to
copy the frame buffer console contents to the root pixmap as it was
created. The trouble here is that the root pixmap is created long
before the upper layers of the X server are ready for drawing, so you
can t use the core rendering paths. Instead, UXA had kludges to call
directly into the acceleration functions.
What we
really want though is to change the order of operations:
- Create root pixmap
- Paint root window
- Set video mode
That way, the normal root window painting operation will take care of
getting the image ready before that pixmap is ever used for
scanout. I can use regular core X rendering to get the original
frame buffer contents into the root window, and even if we re not
using -background none and are instead painting the root with some
other pattern (like the root weave), I get that presented without an
intervening black flash.
That turned out to be really easy just delay the call to
I830EnterVT (which sets the modes) until the server is actually
running. That required one additional kludge I needed to tell the
DIX level RandR functions about the new modes; the mode setting
operation used during server init doesn t call up into RandR as RandR
lists the current configuration after the screen has been initialized,
which is when the modes used to be set.
Calling xf86RandR12CreateScreenResources does the trick
nicely. Getting the root window bits from fbcon, setting video modes
and updating the RandR/Xinerama DIX info is now all done from the
BlockHandler the first time it is called.
Performance
I ran the current glamor version of the intel driver with the master
branch of the X server and there were not any huge differences since
my last Glamor performance evaluation aside from GetImage. The reason
is that UXA/Glamor never called Glamor s image functions, and the UXA
GetImage is pretty slow. Using Mesa s image download turns out
to have a huge performance benefit:
1. UXA/Glamor from April
2. Glamor from today
1 2 Operation
------------ ------------------------- -------------------------
50700.0 56300.0 ( 1.110) ShmGetImage 10x10 square
12600.0 26200.0 ( 2.079) ShmGetImage 100x100 square
1840.0 4250.0 ( 2.310) ShmGetImage 500x500 square
3290.0 202.0 ( 0.061) ShmGetImage XY 10x10 square
36.5 170.0 ( 4.658) ShmGetImage XY 100x100 square
1.5 56.4 ( 37.600) ShmGetImage XY 500x500 square
49800.0 50200.0 ( 1.008) GetImage 10x10 square
5690.0 19300.0 ( 3.392) GetImage 100x100 square
609.0 1360.0 ( 2.233) GetImage 500x500 square
3100.0 206.0 ( 0.066) GetImage XY 10x10 square
36.4 183.0 ( 5.027) GetImage XY 100x100 square
1.5 55.4 ( 36.933) GetImage XY 500x500 square
Running UXA from today the situation is even more dire; I suspect that
enabling tiling has made CPU reads through the GTT even worse than
before?
1: UXA today
2: Glamor today
1 2 Operation
------------ ------------------------- -------------------------
43200.0 56300.0 ( 1.303) ShmGetImage 10x10 square
2600.0 26200.0 ( 10.077) ShmGetImage 100x100 square
130.0 4250.0 ( 32.692) ShmGetImage 500x500 square
3260.0 202.0 ( 0.062) ShmGetImage XY 10x10 square
36.7 170.0 ( 4.632) ShmGetImage XY 100x100 square
1.5 56.4 ( 37.600) ShmGetImage XY 500x500 square
41700.0 50200.0 ( 1.204) GetImage 10x10 square
2520.0 19300.0 ( 7.659) GetImage 100x100 square
125.0 1360.0 ( 10.880) GetImage 500x500 square
3150.0 206.0 ( 0.065) GetImage XY 10x10 square
36.1 183.0 ( 5.069) GetImage XY 100x100 square
1.5 55.4 ( 36.933) GetImage XY 500x500 square
Of course, this is all just x11perf, which doesn t represent real
applications at all well. However, there are applications which end up
doing more GetImage than would seem reasonable, and it s nice to have
this kind of speed up.
Status
I m running this on my crash box to get some performance numbers and
continue testing it. I ll switch my desktop over when I feel a bit
more comfortable with how it s working. But, I think it s feature
complete at this point.
Where s the Code
As usual, the code is in my personal repository. It s on the glamor
branch.
git://people.freedesktop.org/~keithp/xf86-video-intel glamor
Modern desktop environments like GNOME and KDE involving a lot of mousing around and I much prefer using the keyboard where I can. This is why I switched to the Ion tiling window manager back when I interned at Net Integration Technologies and kept using it until I noticed it had been removed from Debian.
After experimenting with awesome for 2 years and briefly considering xmonad , I finally found a replacement I like in i3. Here is how I customized it and made it play nice with the GNOME and KDE applications I use every day.
I have a couple of 
Something straight out from the real world: Menu cards in restaurants are
not nice to deal with if you are blind. It is an old problem we grow used
to ignoring over time, but still something that can be quite nagging.
There are a lot of psychological issues involved in this one.
Of course, you can ask for the menu to be read out to you by the staff.
While they usually do their best, you end up missing out on
some things most of the time.
First of all, depending on the current workload in the restaurant,
the staff will usually try to cut some time and not read everything to you.
What they usually do is to try to understand what type of meal you are
interested in, and just read the choices from that category to you.
While this can be considered a service in some situations (human preprocessing),
there are situations were you will definitely miss a highlight on the menu that
you would have liked to choose if you knew that it was there.
And even if the staff decides to read the complete menu to you (which is rare),
you are confronted with the 7-things-in-my-head-at-once problem.
It is usually rather hard to decide amongst a list of more then 7 items,
because our short-term memory is sort of limited. What the sighted
restaurant goers do, is to skip back and forth between the available options,
until they hit a decisive moment. True, that can take a while,
but it is definitely a lot easier if you can perform "random access reads" to
the list of choices yourself. However, if someone presents a substantial number
of choices to you in a row, as sequential speech, you loose the random
access ability. You either remember every choice from the beginning and do your
choosing mentaully (if you do have extraordinary mental abilities), or you end
up asking the staff to read previous items aloud again. This can work, but
usually it doesn't. At some point, you do not want to bother the staff anymore,
and you even start to feel stupid for asking again and again, while this is
something totally normal to every sighted person, just that
"they" do their "random access browsing" on their own, so "they"
have no need to feel bad about how long it takes them to decide, minus the typical
social pressure that arises after a a certain time for everyone, at least
if you are dining in a group.
In very rare cases, you happen to meet staff that is truly "awake", doing
their best to not let you feel that they might be pressed on time, and
really taking as much time as necessary to help you make the perfect decision.
This is rare, but if it happens, it is almost a magical moment.
One of these moments, where there are no "artificial" barriers between
humans doing communcation. Anyway, I am drifting away.
The perfect solution to this problem is to provide random access browsing
of a restaurant menu with the help of digital devices. Trying to make
braille menus available in all restaurants is a goal which is not realistically
reachable. Menus go out of date, and need changing. And getting a physical
braille copy updated and reprinted is considerably more involved as with digital media.
Restaurant owners will also likely not see the benefit to rpvide a braille
card for a very small circle of customers. With a digital online menu,
that is a completely different story.
These days, almost every blind person in at least my social circles
owns an iOS (or similar) device. These devices have speech synthesis and web
browsers.
Of course, some restaurants especially in urban areas do already
have a menu online. I have found them manually with google and
friends sometimes in the past, which has already given me the
ability to actually sit back, and really comfortably choose
amongst the available offerings myself, without having to bother
a human, and without having to feel bad about (ab)using their time.
However, the case where a restaurant really has their menu online is rather rare
still in the area where I am. And, it can be tedious to google
for a restaurant website. Sometimes, the website itself is just
marginally accessible, which makes it even more frustrating to
get a relaxed dinner-experience.
I have discovered a location-based solution for the restaurant-menu problem recently.
Foursquare offers the ability to provide a direct link to the menu in
a restaurant-entry. I figured, since all you need to do is
write a single webpage where the (common) menu items are listed per restaurant,
that I could begin to create restaurant menus for my favourite locations,
on my own. Well, not quite, but almost. I will sometimes need
help from others to get the menu digitized, but that's just a one-time
piece of work I hopefully can outsource :-). Once the actual content
is in my INBUX, I create a nice HTML page listing the menu in a rather
speech-based browser friendly way.
I have begun to do this today, with the menu of a restaurant just about
500 meters away from my apartment. 
Every now and then I decide I'll try and sort out my VoIP setup. And then I give up. Today I tried again. I really didn't think I was aiming that high. I thought I'd start by making my email address work as a SIP address. Seems reasonable, right? I threw in the extra constraints of wanting some security (so TLS, not UDP) and a soft client that would work on my laptop (I have a Grandstream hardphone and would like an Android client as well, but I figure those are the easy cases while the "I have my laptop and I want to remain connected" case is a bit trickier). I had a suitable Internet connected VM, access to control my DNS fully (so I can do SRV records) and time to read whatever HOWTOs required. And oh my ghod the state of the art is appalling.
Let's start with getting a SIP server up and running. I went with 
A common theme over the last few decades was that we could afford to simply
sit back and let computer (hardware) engineers take care of increases in
computing speed thanks to
My job exposes me to a large variety of computing systems and I regularly use
Mac, Windows and Linux desktops. My main desktop environment at home and work
has been Debian GNU/Linux for over 10 years. However every now and then I take
a little "holiday" and use something else for a few weeks. Often I'm spurred on
by some niggle or other on the GNOME desktop, or burn-out with whatever the
current contentious issue of the moment is in Debian. Usually I switched to
Windows and I used it as an excuse to play some computer games.
Last November I had just such an excuse to take a holiday but this time I opted
to go for Mac. I had a back-log of Mac issues to investigate at work anyway.
I haven't looked back.
It appears I have switched for good. I've been meaning to write about this for
some time, but I couldn't quite get the words right. I doubted I could express
my frustrations in a constructive, helpful way, even if I think that my
experiences are useful and my discoveries valuable, perhaps I would put them
across in a way that seemed inciteful rather than insightful. I wasn't sure
anyone cared. Certainly the GNOME community doesn't seem interested in
feedback.
I turns out that one person that doesn't care is me: I didn't realise just how
broken the F/OSS desktop is. The straw that broke the camel's back was 
Having fun with lisp.
I was writing lisp interpreter in C++ using boost::spirit.
I am happy that my eval can do lambda.
Took me a long time to figure out what was wrong with the different types.
The data structure was recursive, and I needed to make a recursive type.
make_recursive_variant works but it's not obvious when it doesn't.
I just made an account on yet another web service. On the suggestion of my
password manager, I attempted to use the password 
So I was at Ocracoke island, camping with family, and I brought my laptop
along as I've done probably half a dozen times before. An enormous
thuderstorm came up. It rained for 8 hours and thundered for 3 of those.
Some lightning cracks quite close by as we crouched in the food tent, our
feet up off the increasingly wet ground "just in case". The campground
flooded. Luckily we were camped in the dunes and tents mostly avoided being
flooded with 2-3 inches of water. (That was just the warmup; a hurricane
hit a week after we left.)
My laptop was in my tent when this started, and I got soaked to the skin
just running over there and throwing it up on the thermarest to keep it out
of any flooding and away from any drips. It seemed ok, so best not to try
to move it to the car in that downpour.
Next time I checked, it turned out the top vent of the tent was slightly
open and dripping. The laptop bag was damp. But inside it seemed ok. Rain
had slackened to just heavy, so I ran it down to the car. Laptop appeared
barely damp, but it was hard to tell as I had quite forgotten what "dry"
was. Turned it on for 10 seconds to check the time. It was 7:30 and
we still had to cook dinner in this mess. Transferred it to a dry bag.
(By the way, in some situations, discovering you have a single dry towel
you didn't know you had is the best gift in the world!)
Next morning, the laptop was dead. When powered on, the fan came on full,
the screen stayed black, and after a few seconds it turned itself back off.
I need this for work, so it was a crash priority to get it fixed or a
replacement. Before I even got home, I had logged onto Lenovo's website to
check warantee status and found 2 things:
