Re: Re:FW: XFree86 future

On Sun, 2003-03-23 at 19:36, Mark Vojkovich wrote:
> 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.

Assuming that the drivers keep the current code to copy the data
from the source pixmap into video ram immediately before compositing,
I don't think it actually matters:

 ShmImage => 
    PutImage to pixmap in video ram => 
    composite against destination in video ram

 ShmPixmap =>
    copy to scratch buffer in video ram =>
    composite against destination in video ram

Should be more or less identical. 

> > >    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.

Sounds wonderful. 

(For the tuning to work for this application in GTK+, you'll have 
give up accelerating most solid rect fills, but then again, I've 
seen SW solid rect fill code running at full memory burst bandwidth ...
1100Mbyte/sec, so who cares.)

Regards,
                                        Owen