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.
Does the X server make any promises about preserving the contents of the fb memory? EG, if there's a VT switch, will the contents be saved somehow?
Keith
------------------------------------------------------- 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
