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.
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.
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.
My "solution" was to do what drivers on other platforms do: advertise the hardware supported maximum and fallback or block if the allocation fails.
------------------------------------------------------- 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
