On 5/25/09, Luc Verhaegen <[email protected]> wrote: > 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?
I don't know what the S3's capabilities were, but I had to deal with this when developing Solaris drivers for the Permedia 2. Instead of using their useless bitblt, I used a texture fill for all copies. Worked like a charm. Thus was born the PGX32. > > What are those "lot of other things"? It's been a while, so I don't recall, but we ran into problems. > 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. We used cfb for a while after fb was introduced, and we found that some coderot had ensued, and software cursor was broken. Fortunately, we had a large enough hardware cursor that it wasn't a problem. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
