On Fri, 2007-09-28 at 12:10 +0200, Thomas Hellström wrote: > 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
On VT switch everything gets kicked out. The X Server unpins the buffer itself. I'm not seeing the issue there. > 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? Chatting with airlied, he suggested that I commit the code as is to get i915-unification landed so that his superioctl and my 965 work could go forward based on that. The plan is to remove the create memory type flag, and possibly dd one to bo_set_pin, at a later date. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- 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
