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

[Erik Andrén]

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


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

Thanks,
Erik

[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>