Dave Airlie wrote: >>> >>> this adds something to say the kernel initialised the memory region not >>> the userspace. and blocks userspace from deallocating kernel areas >>> >>> >> Dave, >> I guess this commit is a fix for the fact that the X server will try to >> evict fb scanout buffers when leaving VT. We've solved this issue so far >> by having the fb layer evict its scanouts when the X server starts >> before it goes on allocating its own buffers. This was done using >> device-private IOCTLS. >> > > Nope its to do with the fact that if the kernel sets up a memory managed > area, userspace shuoldn't be allowed to just tear it down... so in > modesetting the kernel sets up the areas, running an old X driver then > nukes my memory manager that I'm still using... > > What I'd like to do actually is make the memory managed areas configured > from userspace attach to the master fd as well, so when you nuke > userspace, it self destructs any memory managed areas it setup, while this > has little long term value (as really you need to create the memory areas > in-kernel already) I can see it being useful for a lot of short-term > stuff. > > OK. Hmm, I was confusing drm_bo_clean_mm with drm_bo_lock_mm. > > >> While this is probably desirable to save GTT / VRAM space, I agree it's >> not desirable that the X server or master has the power to evict kernel >> buffers. >> >> What are your thoughts about this? It'd be good to have a common >> practice for upcoming drivers. >> Do we need a mechanism for the X server to clean out it's own buffers >> and the DRI client buffers, or should we just leave them where they are? >> If we want to implement something like that we might have >> drm_bo_clean_mm leave bo_kernel buffers alone instead of the whole >> memory area. >> >> > > So really when the X server exits, all buffers allocated by it need to go > away, or at least get dereferenced, however if it has create memory > managed areas these also need to go away... it should not be destroying > memory manager areas. > I agree.
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... This needs to be addressed in one way or another. /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
