Virtuous blogs

xf86-video-intel 2.5.0

Well, xf86-video-intel 2.5.0 is out finally. About 3 weeks later than we would have liked, but at least we got most of the blockers (nearly all of them in fact) fixed and stabilized the 3D side of the release. As I mentioned in the release announcement this release includes lots of new code and puts us in a good position to really improve EXA and support kernel mode setting quickly.

GTT mapping & pixmap management

One of the things that GEM enables is improved memory management in the 2D driver. In the past, the 2D driver statically allocated several chunks of memory for use by various GPU structures, 2D pixmaps, the front, back and depth buffers, and 3D textures. Needless to say this was fairly inflexible. With GEM in place, most of those static barriers have been eliminated, with the exception of the EXA offscreen pixmap area. Fortunately, EXA (and its close relative, UXA, which is also part of the 2.5.0 release) allow the driver to manage pixmaps if desired. So following the 2.5.0 release I started hacking on the driver to do its own pixmap management. In order to do this well, however, EXA’s PrepareAccess hook should map pixmaps through the GART using write combined access, since the alternative is to map the actual RAM backing store of the GEM object and flushing the CPU caches at FinishAccess (turns out this is fairly slow). This, in turn, means that the kernel needs to allow mapping of objects through the GTT aperture of the CPU’s address space. The patches to allow that are fairly complete at this point, and even include fence register allocation & setup for mapped objects. This should allow us to tile our offscreen pixmaps at some point (fairly soon on 965, and with a little more work on pre-965). As long as we don’t fall back to writing the objects with the CPU very often (thus putting pressure on the limited number of fence registers available and incurring page faults) this should be a performance win.

Kernel mode setting

All of the above is also required for kernel mode setting to work. In a KMS world, the kernel will be allocating a front buffer and will expect the 2D driver to use it for all memory management and fence register allocation. Now that I’ve got these pre-requisites working fairly well, I’ve been able to revisit the KMS code and fix it up in preparation for merging into 2.6.29. Yesterday I fixed merged the latest bits from the drm-next and drm-rawhide branches into the drm-rawhide-intel branch and got a root weave going with a slightly tweaked 2D driver. I should be able to post the required patches this week and get them cleaned up for merging (hopefully next week, assuming the GTT mapping stuff goes in).