On 8/31/05, Eric Anholt <eta@lclark.edu> wrote:> the X Render extension." No, EXA is a different acceleration> architecture making different basic design decisions related to memory> management and driver API.

I did start the EXA section off with this: "EXA replaces the existing2D XAA drivers allowing the current server model to work a whilelonger."

I'll edit the article to help clarify these points but Daniel hasdisabled my login at fd.o so I can't alter the article.

> > "If the old hardware is missing the hardware needed to accelerate render> there is nothing EXA can do to help." Better memory management allows> for better performance with composite due to improved placement of> pixmaps, which XAA doesn't do. So EXA can help.> > "So it ends up that the hardware EXA works on is the same hardware we> already had existing OpenGL drivers for." No. See, for example, the nv> or i128 driver ports, both completed in very short timeframes.> > "The EXA driver programs the 3D hardware from the 2D XAA driver adding> yet another conflicting user to the long line of programs all trying to> use the video hardware at the same time." No, EXA is not an addition to> XAA, it's a replacement. It's not "yet another conflicting user" on> your machine (and I have yet to actually see this purported conflict in> my usage of either acceleration architecture).> > "There is also a danger that EXA will keep expanding to expose more of> the chip's 3D capabilities." If people put effort into this because> they see value in it, without breaking other people's code, why is this> a "danger?"> > --> Eric Anholt eta@lclark.edu> http://people.freebsd.org/~anholt/ anholt@FreeBSD.org> > > -----BEGIN PGP SIGNATURE-----> Version: GnuPG v1.4.1 (FreeBSD)> > iD8DBQBDFUr4HUdvYGzw6vcRAl0SAKCVOCHuVweh5CJoz8UzmkTqNxrEuwCfU/t0> BJVf4HCTUJGn/g4JtsQO0Ds=> =tWVr> -----END PGP SIGNATURE-----> > >