On Mon, 19 May 2008 15:03:50 +0200 Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Hi! > > Parallell to the memory manager discussion, I think we need to revisit > the case of what happens when a > VRAM driver is suspending to memory. > > 1) The ideal thing would be for the card contents to be quickly copied > to backing-store and suspend is done. > However, this requires pinning as much physical pages as there is VRAM. > > 2) The other approach is to have a backing object of some sort, either a > list of swap-entries or perhaps a gem object. > The gem object would, at the point of suspend, either be paged out or > unpopulated which means (provided that the swap sub-system is up at the > suspend point) there will be heavy disk-access and the operation might > fail due to a shortage of either swap space or physical memory for the > swap system bookkeeping. > > Just want to know what's the general opinion here. Are the VRAM card > developers planning to back all VRAM objects with pinned physical pages, > or are we looking at approach 2) which might fail? > > /Thomas The ideal things, from my POV, is to ask to kernel to reserve swap space each time we allocate a buffer, if we ran out of swap space or whatever backing store the kernel can propose then we should fail buffer allocation even if we still have vram available. Idea being that once we migrate out stuff we know that there won't be failure to give us space to save things. Anothers things is to add a hint from userspace which tell if we can drop buffer content, i think we can use such hint for cmd buffer or others temporary buffer we know of, won't save much but still might help to save somebandwidth. Of course this need that kernel provide us an interface for such things. If i am right shmem is already talking with kernel about swap space. Cheers, Jerome Glisse ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
