On Thu, Jan 16, 2003 at 05:33:42PM -0800, Ian Romanick wrote:
> 
> 1. In a scheme like this, how could processes be forced to update the
>     can-swap bits on blocks that they own?

Should it even be possible for one process to swap out other processes'
context data? Alternatively (forgive me if this sounds a bit naive), could
the swapping be handled by agpgart, which just changes the memory mapping
of the allocated pages in the background?  Sort of an added VM layer, only
it would swap to system memory (which could then be swapped to disk)...

> 2. What is the best way for processes to be notified of events that
>     could cause can-swap bits to change (i.e., rendering completion,
>     asynchronous buffer-swap completion, etc.)?  Signals from the kernel?
>     Polling "age" variables?

I'd lean towards signals, myself, though then that leads to possible
problems with libGL using a signal which an application wants to use...  Or
would it be capable of defining new signals?  (I'm not up to speed on how
that part of the kernel works.  Would it just be as simple as adding a new
value to an enumeration?)

> 4. How could the memory manager handle objects that span multiple
>     blocks?  In other words, could the memory manager be made to prefer
>     to swap-out blocks that wholly contain all of the objects that
>     overlap the block?  Are there other useful metrics?  Prefer to
>     swap-out blocks that are half full over blocks that are completely
>     full?

If the AGP layer were to treat it like a VM layer and the page size were
small (say, 4K) I don't think this would be an issue.

-- 
http://trikuare.cx


-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com
Understand how to protect your customers personal information by implementing
SSL on your Apache Web Server. Click here to get our FREE Thawte Apache 
Guide: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0029en
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to