Eric Anholt wrote: > libdrm/xf86drm.c | 26 ++++ > libdrm/xf86mm.h | 1 > linux-core/Makefile | 1 > linux-core/drm_bo.c | 249 > ++++++++++++++++++++++++++++++++++++----------- > linux-core/drm_drv.c | 3 > linux-core/drm_ioctl.c | 25 ++-- > linux-core/drm_objects.h | 3 > shared-core/drm.h | 29 +++-- > 8 files changed, 254 insertions(+), 83 deletions(-) > > New commits: > diff-tree 24e33627c5dfb92324a9faf1c7d366e7f33e622a (from parents) > Merge: 7587e9682c1b70930c015915d588b42ccd00c7c4 > e7bfeb3031374653f7e55d67cc1b5c823849359f > Author: Eric Anholt <[EMAIL PROTECTED]> > Date: Fri Sep 21 17:05:21 2007 -0700 > > Merge branch 'bo-set-pin' > > This branch replaces the NO_MOVE/NO_EVICT flags to buffer validation with > a > separate privileged ioctl to pin buffers like NO_EVICT meant before. The > functionality that was supposed to be covered by NO_MOVE may be > reintroduced > later, possibly in a different way, after the superioctl branch is merged. > Eric,
I'm a bit curious about this commit. At XDS there were some wishes to a) Get rid of the memory specification flag at buffer object creation. b) Get rid of the validate call altogether, forcing non-root clients to use the superioctl. Then with the current set pin interface we have no way to specify where we want to pin the buffers, So either we need to specify this in the set pin interface or perhaps keep a validate interface with a mandatory "Don't fence", just to set the buffer flags, but then there's no real need for the set_pin interface. Another functionality we need to keep is to move out the scanout buffers before releasing them on VT switch, so that we don't fragment memory. That's currently done by drmBOValidate(xxx, DRM_BO_MEM_LOCAL , DRM_BO_HINT_DONT_FENCE); // Unpin and move out. drmBOUnreference(xxx) // Unreference. DRI clients need to unreference next time they take the lock. but basically we want to set some kind of zombie buffer state here, to be able to release the pinned pages. This functionality also basically need a validate / whatever we name it functionality left in there. So, what are your plans for this? /Thomas ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. 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
