Re: Re:FW: XFree86 future

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.

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

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

(Cost of migration depends on hardware ... I seem to remember you
quoting quite good speeds for copying data out of video memory
with your nvidia drivers, but this isn't typical.)

Regards,
                                        Owen