On Wed, May 13, 2009 at 10:49:30AM -0400, Timothy Normand Miller wrote: > When it comes to memory management and a lot of other things, EXA is > way better than XAA, but EXA doesn't provide means to support many 2D > functions, even if your hardware supports it. And when you try to > bypass EXA or XAA altogether (gc-level), then certain things don't > work right, like software cursor.
A few weeks from now, it'll be 4 years since the original talk presenting EXA. Ask yourself; why are people still talking about EXA versus XAA today? Exa is like so many of the things in the post-xfree86 X.org world: * start from scratch, strive to kill off whatever was there before. no intention to evolve things or to learn from older implementations. * big promises that barely get delivered upon, and a lot of vagueness promising that "things" will be better in general in future. The major promises are usually silenced to death several years later. And when one would reasonably expect this given future to have happened, all there is is a lot of promises for the next big future. * painful transition, years of suffering, drivers getting broken almost deliberately so that deprecation can happen soon. So what memory management then? Do you know many driver where the scanout/offscreen can be moved around freely then? The difference with XAA was, XAA was developed with early accelerators in mind, and had a fixed fb pitch set up once (S3 had a fixed pitch). EXA sets up the pitch _all_ the time. How hard would it have been to fix up parts of XAA instead of throwing it away completely? What are those "lot of other things"? And what do you mean, bypass exa or xaa at gc level? Iirc, the GC is, for a given pixmap or whatever abstraction uses it, the structure with callbacks are attached. If you've ever had to deal with them, then you know that those callbacks are being altered all the time. When EXA or XAA cannot support a given set of operations on a given pixmap (or whatever) at a given location, then you'll quite quickly have FB hooks attached. So those hooks can be anything; from direct writing into the framebuffer, to shadowfb or some higher level code calling into hw accel callbacks. A software cursor is not treated differently. Luc Verhaegen. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
