On Fri, Oct 10, 2003 at 11:16:06AM +0100, Keith Whitwell wrote: > Alan Hourihane wrote: > >On Thu, Oct 09, 2003 at 06:36:11PM +0100, Keith Whitwell wrote: > > > >>Alan Hourihane wrote: > >> > >>>On Thu, Oct 09, 2003 at 05:30:08PM +0100, Keith Whitwell wrote: > >>> > >>> > >>>>Alan Hourihane wrote: > >>>> > >>>> > >>>>>I've just committed a version of the DRI's common code mm.[ch] linear > >>>>>allocator > >>>>>into the XFree86 CVS which extends the FBManager's ability to serve > >>>>>real linear space rather than pinching it from the XY area's that's > >>>>>usually occupied by the pixmap cache. > >>>>> > >>>>>This way we can now hand over all memory to the FBManager and allow it > >>>>>to give us back memory regions, rather than using the current scheme > >>>>>of semi-dynamic allocation that relies on fixed offsets but cannot > >>>>>guarantee those offsets in certain situations. > >>>>> > >>>>>So, I've moved onto the next stage of implementing the dynamics in the > >>>>>r200 driver which has shown some tricky pieces to solve with regard > >>>>>to allowing dynamic memory management. > >>>>> > >>>>>For testing purposes, I've added another ioctl to the r200 interface > >>>>>to pass the new back/depth offsets to the kernel driver and update > >>>>>these offsets & the texture offset in the DDX driver on transitioning. > >>>>>The problem is that TransitionTo3D() is called too late to setup these > >>>>>new offsets. > >>>>> > >>>>>To explain a little.... > >>>>> > >>>>>We get the current device information during the initial screen setup > >>>>>by issuing the DRIGetDeviceInfo() call into the Xserver to retrieve > >>>>>these driver private details. If we modify them after this initial > >>>>>setup > >>>>>(which we do with transitioning) then we need to retrieve new private > >>>>>details to act upon. Currently I've inserted another DRIGetDeviceInfo() > >>>>>call into the r200_context.c to pick these up and moved the (modified) > >>>>>code > >>>> > >>>>>from TransitionTo3d() in the DDX to the DDX's CreateContext() function. > >>>> > >>>> > >>>>>This works, but seems rather messy. > >>>> > >>>>Could we add this state to the existing mechanisms that exist to > >>>>communicate cliprect changes between XFree86 and the driver? > >>>> > >>>>That is, if the driver detects that it's drawable has been invalidated > >>>>(look at r200GetLock()) the new semantics would be that the driver > >>>>should both > >>>> - Ask the X server for a new set of cliprects (as it currently does) > >>>> - Ask the kernel module (or X server) for the new buffer locations > >>>> > >>>>This may be more dynamic than you needed, but maybe a future step might > >>>>require this level of control? > >>> > >>> > >>>It could be added at this stage - yes. But as you say, it's a little > >>>more dynamic than needed currently. It means changing the > >>>DRIGetDrawableInfo() > >>>call, thus requiring a version bump (which it would anyway as there'd be > >>>new protocol). > >> > >>I'm not necessarily suggesting new protocol -- just get the driver to do > >>two things where it currently does one. Where previously there was a > >>call to DRIGetDrawableInfo(), add a call to GetBufferOffsetIoctl(). Or > >>DRIGetBufferInfo() if you wanted to ask the X server. > > > > > >But it's a case of if I add this extra DRIGetBufferInfo() call then we'll > >need to work out how to get it to work with older drivers. > > > > > >>>Actually putting it at this stage, may well work out. If we ever > >>>allow a non-unified back buffer architecture and allow per window > >>>back buffers to reduce the memory footprint furthur. > >> > >>Yes - that's what I was thinking of... > >> > >>We have to decide who's the boss of this memory -- the kernel or the X > >>server. Previously we'd assumed that it would be the kernel, but that > >>isn't necessarily the case as the X server already has a memory manager > >>that could do the job, right? > > > > > >Right. And certainly now with the new linear allocator the Xserver can > >manage the whole lot. > > Does the X server make any promises about preserving the contents of the fb > memory? EG, if there's a VT switch, will the contents be saved somehow?
No. No preservation is done. We need to invalidate everything. Alan. ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
