Dave Airlie wrote: >> So, over to the somewhat different problem I was referring to, namely >> potential buffer eviction on vt switch where the X server run >> drm_bo_lock_mm(), and will evict any fb scanout BOs. Only the fb layer >> doesn't really notice as long as the BOs sit in VRAM... >> > > Yes I get around this currently by not having the X server call it on > modesetting systems. Clearly I need a better answer which may be that we > ignore it in the kernel, unless it comes from a control node process.. > > when does locking the mm make actual sense? just VT switching? > > Yes, I think so. One reason to lock is to make sure the GTT page table is really repopulated after a resume, but that can be handled in the DRM driver resume function, and we could perhaps change the user-space lock_mm() to ignore kernel_bos.
We also have a another possibility where an ioctl makes the drm fb evict its scanout buffers and one that brings them back. This preserves aperture space when X is doing its allocation, but it's abit error-prone since it requires that fb can live with updated offsets and kernel virtual addresses. It apparently can, but there's no mutex generally protecting these variables so it seems quite fragile. /Thomas > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
