[Intel-gfx] xf86-video-intel 2.5 release planning

Erik Andrén erik.andren at gmail.com
Fri Aug 1 08:05:16 CEST 2008

2008/7/31 Jesse Barnes <jbarnes at virtuousgeek.org>

> It's my turn to handle a 2D driver release again, so I've been thinking
> about
> what we should include (and remove!) in the 2.5 release.  I've created a
> blocker bug for the release, 16926, and I'm interested in hearing about
> bugs
> you think should be added.  The 2.4 release was a bit late; I'd like to
> avoid
> that this time around, and want to do the first -rc hopefully by
> mid-August.
> Target highlights for this release include:
>  1) usable EXA support
>  2) support for GEM (if supported by the currently running kernel)
>  3) support for kernel mode setting (again, if the underlying kernel
> supports
>     it)
>  4) no more video tearing with textured video & XvMC
>  5) Bug fixing
>  6) removal of XAA code
> See below for details.
> 1. Usable EXA support
> Carl recently pushed some fixes that should make EXA better than XAA
> (finally): http://cworth.org/blog/technical/.  Assuming the users
> reporting
> performance regressions with EXA vs. XAA are happy with the changes, things
> are looking good here.
> 2. Support for GEM
> The drm-gem branch of xf86-video-intel has been under development for
> awhile
> now, and gracefully falls back in the case where no kernel support is
> available.  I'd like to merge this into master to get it some more
> coverage.
> Ideally, we'd get the Mesa drm-gem branch merged into master as well,
> making
> it much easier for people to play with GEM stuff (just boot a new kernel or
> insmod some new DRM modules and restart), but the Mesa bits need a little
> more review first.
> 3. Support for kernel mode setting
> Along the same lines, we'd like to make it easy for people to test the
> shiny,
> new kernel mode setting bits.  The 2D driver changes aren't hugely invasive
> (and they give me an excuse to clean some stuff up), so I'm planning on
> merging them to master, again to make testing of new kernel bits easier for
> everyone.
> 4. No more video tearing
> One of our #1 complaints since adding textured video support is tearing.
>  It
> seems to occur in both composited and non-composited configurations,
> depending on what else is going on in the system.  With recent changes to
> Mesa, hopefully the composited case can be solved by making the compositing
> manager use scheduled buffer swaps (i.e. using glxSwapBuffers with
> vblank_mode=3 or similar), but in the non-composited case we'll need to
> make
> our Xv and XvMC code a bit smarter.
> 5. Bug fixing
> Catch all for fixing display bugs, suspend resume problems, improving LFP
> detection, fixing SDVO bugs, etc. (there are quite a few display bugs
> Zhenyu
> & I want to tackle for this release)
> 6. No more XAA
> Back in 2.2, we made EXA the default acceleration architecture for the
> driver.
> It obviously wasn't quite ready back then for everything people were
> throwing
> at it, but OTOH it didn't have some of the fundamental shortcomings of XAA.
> It looks like it's finally ready though, so assuming Carl has EXA
> performance
> well in-hand, we should be able to delete the XAA code altogether (which
> will
> be nice since it doesn't support several features and has bugs we don't
> want
> to fix).
> Please direct comments & questions to myself and the list.
> Thanks
> Jesse

the highlights above do look nice.
Are there any plans on further optimizing the power efficiency of the
I'm thinking on stuff like Matthew Garrets LVDS reclock patch [1].


[1] http://mjg59.livejournal.com/92646.html

> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20080801/a0b7f418/attachment.html>

More information about the Intel-gfx mailing list