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

Jesse Barnes jbarnes at virtuousgeek.org
Thu Jul 31 13:17:41 PDT 2008


On Thursday, July 31, 2008 1:08 pm Alan W. Irwin wrote:
> On 2008-07-31 11:56-0700 Jesse Barnes wrote:
> > 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).
>
> Jesse is well aware of this already, but just to let others know here,
> there continues to be long-term EXA instability problems compared to XAA
> that show up after a week to a month of continuous use, see
> http://bugs.freedesktop.org/show_bug.cgi?id=14464.

Yeah, we've got a few similar bugs open; given that it only happens with EXA 
it's likely to be a render accleration bug (Option "ExaNoComposite" "true" 
would eliminate the crashes in that case) or an interaction between the EXA 
code and the 3D driver.  I'll add this one to the blocker list though; I 
don't want to remove XAA until EXA is stable.

> I never had such problems when using XAA for many years but EXA is stable
> enough in the short term that I always run it now and put up with the
> necessary reboots.  Thus, I don't really need XAA for my normal X use.
> However, availability of the XAA alternative as a benchmark might be
> beneficial to the developer who finally attempts to track down this
> long-term instability problem.  Also, some users who are used to the XAA
> stability may feel stronger than I do about removing it. Anyhow, that is
> one potential downside of ripping out XAA which I thought I should mention.

Yeah, thanks for bringing it up.

Jesse



More information about the xorg mailing list