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?
Having said that, I remember now why I put the current code in the r200's CreateContext routine - so, no we can't without a little more work. There isn't a drawable on Context creation and currently the texture heap code requires it knows how big the texture heap size is to calculate the mipmap levels. We won't know the texture heap size until we've retrieved our private data again. Maybe this can be overcome with some tweaks to the texmem.c code ? 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
