On Sat, 2007-09-29 at 00:24 +0200, Thomas Hellström wrote: > 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.
RandR FB resize is just: disable crtcs scanning from buffer allocate new buffer unpin old buffer copy operation from old to new pin new turn on crtcs pointing to new. You've got to blank the screen anyway if you're changing mode, so disabling it around the copy is just fine. The only case not covered is extending the FB to put a new crtc to the side/above/below and not flickering the currently-enabled CRTC. If you wanted to attempt that you just try setting up two pinned buffers at the same time, doing the copy, pageflipping between them, and then doing another series of the same if you want to optimize memory layout afterwards, and falling back to the above if you can't manage it. But this doesn't seem like a very useful effort currently, since it doesn't deal with the fact that you've got ugly intermediate states being shown anyway as your desktop environment tries to re-fit itself to the bigger FB. -- 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
