We’ve been working furiously to get everything merged for the next xf86-video-intel release. Eric has been working to get the new GEM subsystem merged into 2.6.27 (though it looks more likely that it won’t get in until 2.6.28), Keith has been hacking on a UMA X acceleration architecture to play with some ideas about acceleration with GEM, and I’ve been working on merging things into the master branch of xf86-video-intel, along with getting modesetting-gem in the DRM tree into shape for a upstream kernel push.
As of this week, the drm-gem branches (in xf86-video-intel, mesa and drm) are no more, everything is in master now. This means that with a suitably capable kernel, you can run the latest bits and get all the GEM goodness you’ve been craving. With that out of the way, I’ve been working on porting the old, intel-kernelmode branch into master. I’m pretty close to actually getting X up and running now using the modesetting-gem bits of xf86-video-intel and drm, but I still have a bit of work to do in the EXA prepare/finish access routines. Related to that, I’ve been adding GTT mapping support to GEM, so that 2D fallbacks don’t suffer too terribly (hopefully I can figure out a way to map objects into tiling fence registers as well for even better performance). That work is totally untested at this point though; I’ll get things running slowly first, then finish the new mapping function and try it out.
Next week I should be able to finish that merge, get things running, put together a PCI pull request for Linus (there are some good bug fixes in my queue that really should have gone upstream a week or two ago) and fix some gfx bugs. After that I hope to have a look at the PCI allocation stuff. If we can get that right, 2.6.28 may be the release that gives people a lot more address space for their PCI cards, meaning everyone can use more devices and will see fewer, mysterious “resource allocation failed” messages at boot time.
..
Complete Story
0 comments:
Post a Comment