On Mon, 17 May 2004, Ville [iso-8859-1] Syrjälä wrote:
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.
Very interesting..
How is that sort of thing going to work inside the kernel?
Why not ? There are certainly places with a lot more complex code
(say page management on i368) so if this is what is needed then why not.
However, I am not certain that the code for deciding what to throw out
belongs in the kernel in the first place. This can be a user-space policy.
This way the kernel-side memory management mode knows only about:
1. partition of the video RAM
2. flags (can be freed, cannot be freed, can be freed after a given
age)
3. age when a given portion can be freed.
4. priority of freeing.
It is up to userspace to the set the flags, age and priorities right.
Does this make any sense ?
best
Vladimir Dergachev
--
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
