Eric Anholt wrote: >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. > > Hmm, you're right. VT was a bad example. Releasing and reallocating a buffer on an xrandr event is a better one, where we need to issue the sequence below.
>>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. > > > OK. I guess I'd like to see the setPin functionality being more or less like validate is today with the additional restrictions that it is root-only and doesn't put anything on the unfenced list. I'd like to be able to specify memory types and also pinned and possibly "zombie" state. will that work OK with your current work? /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 > > ------------------------------------------------------------------------- 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
