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. 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
