Re: Re:FW: XFree86 future

On 23 Mar 2003, Owen Taylor wrote:

> On Sun, 2003-03-23 at 18:28, Mark Vojkovich wrote:
> > On 23 Mar 2003, Owen Taylor wrote:
> > 
> > > There is also the major problem right now that if you have sufficient
> > > video ram but no HW compositing, X will be doing framebuffer _reads_
> > > to alpha composite. (And for 16bpp color, 16 bit framebuffer reads
> > > at that.) There are various solutions here at varying levels
> > > of complexity. Most simply, a way for GTK+ to say "if you don't
> > > have HW render, don't put this pixmap into video RAM" would work
> > > fine.
> > 
> >    The solution is to have XFree86 kick out those pixmaps. 
> > I posted code to do that before.  Nobody commented on whether
> > it solved the problem or not.
> 
> Looking back through the [email protected] mailing list, all
> I really see is a pseudo-patch for kicking _source_ pixmaps
> out of video ram. While what I'm talking about here is destination
> pixmaps. With current XAA, source pixmaps in video memory is
> a problem for HW accelerated compositing, but if you are
> falling back to software, both the source and destination
> should be in system ram.

   A similar thing could be done for destination pixmaps.
Render is implemented through screen funcs so there's not
a problem kicking things out at that point (unlike GC funcs
where you'd mess up the validation).


> 
> (For the local case, GTK+ has a hack to keep source pixmaps out of 
> video ram ...it uses ShmPixmaps when possible.)

   This causes a big performance limitation long term because that
prevents acceleration, even if the driver could have done it.


> 
> >    Anyhow, the new XAA is much smarter about this.  Pixmaps
> > get migrated in and out of video ram based on their useage. 
> 
> Certainly migration is better than nothing, but not migrating
> is even better. Sending data over the bus to immediately 
> pull it back out, or doing reads over the PCI bus to migrate
> a constant-color pixmap back to the system is a bit of a
> waste.


    It all fits into the equation.  Pixmaps start out in system
memory and don't get moved to video ram unless they establish
a history of operations that would be better done in video ram.
When things are in video ram when they shouldn't be, they get
severely punished and don't get a shot going back into video ram
unless they establish an even longer history of doing things
that would be better done in video ram in the future.  I've
spent alot of time tuning this.


			Mark.