On Thu, Oct 09, 2003 at 12:04:08PM -0700, Ian Romanick 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. > > We're trying to move to an architecture where driver binaries can be > used both with and without X. I'm working on a description right now > (should be sent out later today) of how to move almost all of the X > protocol calls out of the driver binary. In my proposal, the only calls > the will remain (modulo backwards compatability) are > XF86DRIGetDrawableInfo, XF86DRICreateDrawable, and > XF86DRIDestroyDrawable. My plan is to export those using the > glXGetProcAddress mechanims. At that point the driver binaries won't > rely on any X protocol releated functions that are statically exported > from libGL.so. Moving to an architecture where driver binaries can be used both with and without X is definately a priority. Although from what you mention your targetting the 3D driver. I'm targetting both the DDX driver and the 3D driver. So how far away are you from completing your goal for the 3D portion ?
I'm working on wrappers for the DDX driver so that MiniGLX in Mesa can use the same code and we'd no longer need to use a full XFree86 tree, or even need access to the rest of the DDX(2D) driver. > Adding calls to XF86DRI* directly to the driver code or via wrappers in > dri_util.c will defeat this. If possible, please export these calls via > the glXGetProcAddress mechanism instead of as statically exported symbols. O.k. That's possible. > >>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 ? > > The current method of mipmap calculation is just wrong. Back when I was > actually able to work on the next generation of texture management code, > I had canned this whole mechanism. As you point out, unless memory is > statically partitioned *AND* texture memory can always instanatly be > reclaimed, the current system just doesn't work. Right. > My "solution" was to do what drivers on other platforms do: advertise > the hardware supported maximum and fallback or block if the allocation > fails. Indeed. The was my initial reaction was to export the full hardware supported maximum and fallback when the allocation fails. If that's acceptable by others then let's do that. 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
