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