> > 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? >
By default for a laptop system you *have* to have swappable backing store for everything in VRAM preallocated, not pinned, but available. Failing suspend is not the answer, as user closes laptop lid, and sticks it in bag, he doesn't expect it not to suspend because he has blender and compiz running or whatever. So we have to fail on object allocation if we have no backing store available. Now I would be willing to provide a drm tuneable sorta like memory overcommit that could be used on embedded systems and basically says I've designed my system so I never need suspend/resume and I really udnerstand what I'm doing, so don't ensure I have backing store for VRAM allocations. This would never be the default. Dave. ------------------------------------------------------------------------- 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 Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
