On 6/16/05, Keith Whitwell <[EMAIL PROTECTED]> wrote: > But, if you implement your scheme, by the same logic you need another > 512mb of system ram just to make things work. If you've got all that > extra ram hanging around, you could implement the single copy scheme and > when a suspend occurs, pull the vram back to that extra system ram > (which you would have needed anyway), rather than going to disk.
The only way to preserve the VRAM contents across suspend/VT swap is to copy it to system RAM. The fbdev drivers can do this, but they don't know what is important in VRAM and what can be regenerated so they just have to copy the whole 512MB (15 seconds). The DRM drivers know what is important but they don't know when suspend/VT swap is happening because there is only one set of kernel hooks and the fbdev driver is attached to them. The scheme where a texture copy is kept in system RAM doesn't depend on the DRM driver having suspend/VT swap hooks since it is able to rebuild VRAM at any point. So, given the way things are now, we have to pick one of the first two choices. Doing anything else (like doing a minimal copy out of VRAM) requires the drivers to be linked. Too many people are opposed to merging DRM/fbdev for that to happen. -- Jon Smirl [EMAIL PROTECTED] ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
