> > I'm definitely thinking we need to take Ian's DriMemoryManagerDesign > document and start thinking throught the issues.. it needs to be expanded > to be able to manage all graphics memory, VRAM and AGP, including > framebuffers and all that stuff, every driver using should allocate via > it, no more X 2D memory manager and all that .. being able to resize > framebuffers etc by dropping all the clobberable blocks, and moving other > stuff around would be a good start...
I've sort of said it above, but just to re-iterate I know longer think we are looking at a DRI Memory Manager, this should really be a VRAM memory manager for everything, not just 3d objects... I think projects like DirectFB should also be able to use it.. and even fbdev driver should interact with it if they want... i.e. if anything in the system wants some VRAM it must go through this.. this will probably change where we want to place the kernel/user boundary, I think Ians current design is too biased towards userspace and DRI requirements in its current form... Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
