> > > > 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. > 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. 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
