Dave Airlie wrote: > libdrm/xf86drm.c | 15 ++++++++++ > libdrm/xf86mm.h | 1 > linux-core/drm_bo.c | 67 > +++++++++++++++++++++++++++++++++++++++------- > linux-core/drm_drv.c | 2 + > linux-core/drm_objects.h | 8 ++++- > shared-core/drm.h | 6 ++++ > shared-core/nouveau_mem.c | 6 ++-- > 7 files changed, 90 insertions(+), 15 deletions(-) > > New commits: > commit d5c0101252e9f48ef1b59f48c05fea7007df97f0 > Author: Dave Airlie <[EMAIL PROTECTED]> > Date: Mon Feb 18 10:39:21 2008 +1000 > > ttm: make sure userspace can't destroy kernel create memory managers > > 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.
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. /Thomas ------------------------------------------------------------------------- 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
