Permalink 03:45:13 pm, by jbarnes Email , 270 words, 13936 views   English (US)
Categories: Announcements [A]

back from drinking island

It’s been an exciting few weeks since my last post (well ok 6 weeks):

  • DRM KMS merged (woo-hoo!)
  • Wayland running on top of DRM KMS - had fun with Kristian on this one while we were both visiting Hillsboro for Intel meetings
  • lots and lots of bug activity

The downside of the KMS merge is a boatload of new kernel bugs :p but that’s to be expected. We still have quite a few 2D bugs open and those will start to migrate over to the kernel side as more and more people use the code. I’ve got some cleanups to the libdrm doxygen markup as well, but nothing I’m ready to push out (it seems there’s always a more important bug or feature to work on so docs keep getting delayed, so dear lazyweb please write it for me etc etc).

On the home front things have been fun too; my new office (a shed in the back yard I’ve been remodeling) is nearly ready to move in to, just a few more weekends worth of work to go. It’s been a fun project, but I’m really ready for it to be done now, since I need the space and freedom from distraction it should bring. The holidays were great as well. Our little family visited my parents for the week of Christmas and had a lot of fun with the clan (grandparents, great grandparents, aunts, uncles, cousins from all over came to visit). Then for new year’s my sister finally got to visit us up here in Arcata.

Well anyway, back to herding PCI patches and fixing up the KMS bits.


Permalink 11:46:00 am, by jbarnes Email , 683 words, 21835 views   English (US)
Categories: Announcements [A]

reflecting on releases

Releases in graphics land

I’ve spent a lot of time recently getting some fairly ancient pieces of work pushed up stream, and it got me to thinking about how quickly we push new code upstream in the DRM, xf86-video-intel, Mesa and X server trees.


My primary interest lately has been the DRM tree, where two of the big features I’ve helped create took way too long (IMO) to land on actual user machines. So how have we done there?

2.6.27..today6346 files changed, 7894 insertions, 2132 deletions
2.6.26..2.6.274994 files changed, 58047 insertions, 0 deletions (tree moved to drivers/gpu)
2.6.25..2.6.263829 files changed, 2937 insertions, 1335 deletions
2.6.24..2.6.254763 files changed, 2721 insertions, 956 deletions
2.6.23..2.6.241765 files changed, 2388 insertions, 3153 deletions
2.6.22..2.6.232777 files changed, 2609 insertions, 2528 deletions

Honestly, I expected to see more quantitative evidence of the qualitative changes we’ve made recently, but maybe that’ll take awhile to show up in the stats. The real issue though is the disparity in commits to the DRM tree vs. what got merged upstream: there were 1165 commits to the DRM tree in the timeframe above, including fairly infrequent libdrm changes, while the kernel only saw 241. At a high level that would seem to indicate that we did a pretty poor job of keeping the upstream kernel up-to-date, at least until recently.


For xf86-video-intel, I think things have been pretty good since we started doing quarterly releases. Our time based schedule means that users get new features and bug fixes in a fairly timely manner, though there occasional exceptions like feature trees that don’t get merged for a long time, if ever. For example the batchbuffer and kernel mode setting branches never got merged (though support for those features ended up in master anyway in different forms). We’ve been doing this for long enough that I don’t think commit stats would mean much (though it would be intresting to plot commit counts over time along with bugs reported and fixed I’m not going to do that today).


Mesa tends to see a lot of churn since it includes both the core 3D engine (and Gallium too these days) and all of the supporting drivers. Its release schedule isn’t as predictable as the kernel’s or xf86-video-intel though, which makes it hard to know when a given fix or feature will end up in the hands of users. AFAICT it operates on the “when it’s ready” release schedule, which is good and bad. Releases tend to be stable and long lived, but new features and fixes sometimes take awhile to get out. This is why for Intel we end up doing branched releases of Mesa every quarter so our latest driver fixes are available to distros and users right away. Any changes to the way Mesa works would probably need more developer time, which is fairly scarce in the open source graphics world, so I don’t expect this to change anytime soon. (I didn’t dig through the Mesa logs to see how things are here, so dear lazyweb etc.).)

X server

What can one say for the X server itself? Let’s see how frequent those releases are:

xorg-server-1_1_0May 22, 2006ajax
xorg-server-1.2.0January 23, 2007ajax
xorg-server- 19, 2007keithp
xorg-server-1.4September 6, 2007anholt
xorg-server-1.5.0September 3, 2008ajax

Releases have been all over the place, from about a year apart to a few months, with correspondingly inconsistent release tags. I think this reflects both a lack of developer power and lack of clear ownership for the X server: no one person or organization “owns” the X server enough to make sure releases happen frequently, and getting people to fix server bugs for a given release is like herding cats, so release managers end up with the herculean task of doing everything themselves. Personally, I think pulling the drivers back into the server module would alleviate this somewhat, since it would give driver developers an interest in making sure the server is in good shape, and probably also induce them to work on server features and bugs so that releases could happen on a regular schedule. Very few people share this opinion though, so I’m not hopeful that people will agree to it anytime soon.


Permalink 07:55:57 pm, by jbarnes Email , 164 words, 13902 views   English (US)
Categories: Announcements [A]

random update

kernel mode setting requirements

I’m hacking on getting the core DRM mode setting code ready for merge this week, along with the i915 code, but I’m not sure if my posts made the requirements for testing clear.

I posted a patchset for core, i915 and radeon mode setting to the dri-devel list recently, but there are a few other patches required in order to test those bits (which btw are very raw; I was able to get a root weave from X but things were pretty crashy if I tried to rmmod/insmod the module again). Anyway, if you want to live on the bleeding edge, you’ll need my xf86-video-intel EXA pixmap patch, and my libdrm &amp drm patches for GTT mapping.

Note that we don’t currently track per-pixmap tiling, so you may have to disable tiling in your xorg.conf to avoid corruption (either that or force every pixmap to be tiled in i830_exa.c at map or creation time).


Permalink 11:40:26 am, by jbarnes Email , 466 words, 28559 views   English (US)
Categories: Announcements [A]

GTT mapping 101

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).


Permalink 08:36:10 am, by jbarnes Email , 374 words, 12167 views   English (US)
Categories: News

and more travel...

And just when I thought I was done travelling for awhile… Turns out I have to spend a few days in London for top secret meetings (should be good actually but it would be nice to be home for a change).

On the plus side, GEM looks like it’s finally queued up for 2.6.28! This is huge, since we’ve all been waiting for some kind of memory manager to land for many years now. If there’s any justice in the world, Eric should never have to buy beer again in the company of anyone even slightly involved with Linux graphics and desktop development.

With that out of the way, some of the other stuff queued up behind the memory manager can finally land; Dave and I had talked with Linus about merging the kernel mode setting bits, but now that I’m out of the loop for a week or so I’m not sure if I’ll be able to help much with that (not to mention that I’m trying to fix what I hope is the last issue with my GEM GTT mapping patches, which now include fence register management, so that xf86-video-intel with GEM based pixmap management becomes viable). DRI2 should also be coming soon, though I haven’t talked with Kristian about it recently.

This quarter’s release of the Intel driver has been somewhat delayed though, despite all the good news. Trying to stabilize the GEM stuff on the 3D side took a lot of Eric’s time, but it looks like things are in reasonable shape there now. We’ve fixed a few of the more offensive 2D bugs recently too, but there are still more open than I’d like at this point, but I suppose we can always do point releases later as things get fixed up. So when a new libdrm comes out (which should be possible now that GEM is queued up and the interfaces are stable) I should be able to spin the final 2.5.0 package, completing the 2D side of the release.

Well, more later. I have to go dig up a separate machine so I can figure out what’s going on with my GTT mapping code (no kernel mode setting means I can’t see the panics I’m causing yet, sigh).

<< Previous Page :: Next Page >>

Virtuous blogs

< Previous | Next >

February 2018
Sun Mon Tue Wed Thu Fri Sat
 << <   > >>
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28      



XML Feeds

What is RSS?

Who's Online?

  • Guest Users: 23

powered by b2evolution free blog software