On Sun, May 16, 2004 at 08:08:10PM -0700, David Bronaugh wrote: > Vladimir Dergachev wrote: > > This brings out an interesting memory management point: swappable versus > non-swappable graphics objects. > > A framebuffer is obviously non-swappable, while textures are swappable.
Not just textures but other offscreen buffers as well. With a compositing window system all windows have offscreen or system memory buffers. And then there are font glyphs, pixmaps etc. The problem here becomes how to determine what to throw out and what to do when things get kicked out. Also memory fragmentation can be a problem. If we want to handle all of this the system will start to look like DirectFB's memory allocator. Currently DirectFB manages all of the offscreen memory and all memory chunks have a usage counter so it can decide what to throw out. If the surface in question has a system memory buffer as well we make sure that it's updated before the video memory copy is thrown out. How is that sort of thing going to work inside the kernel? -- Ville Syrj�l� [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
