On Sat, Jun 05, 2004 at 03:09:54AM -0400, Patrick McFarland wrote: > > Which brings me to mention something else: I fully believe that the > kernel should be completely managing all aspects of memory and state > management of both 2D and 3D hardware. The kernel's portion of DRI > should be providing methods to allow multiple DRI using apps (such as > multiple xservers running at once) and multiple opengl apps within a > single DRI context to work flawlessly with each other. > > Currently, projects such as DirectFB suffer because there is really no > unified method to do this. DirectFB nor xservers should ever be managing > memory on their own, nor managing parts of the DRI context on their own. > It becomes very easy to get different peices of software to break each > other, or simply prevent each other from working at the same time. > > This, however, requires a more unified driver system (on platforms that > support it) between DRI and fbcon. (Does BSD have an equivilent to this?) > This new hybrid system would do all memory management,
I agree, the kernel should manage video and AGP memory. > do the actual > resolution and depth changes, I agree with this one too. But the interface should be more flexible than what fbdev provides. And it should handle overlays as well. > expose 2D and 3D hardware acceleration > functions, allow applications (DirectFB, xservers) to query the > available acceleration methods, I disagree. This part of the kernel should be as dumb as possible. I think the best interface would be simply one accepting almost complete DMA buffers. The only thing missing from these buffers would be real memory addresses. The client should just use a surface id (handed out by the memory allocator) instead of a real address. The kernel would then check if the client is allowed to use those surfaces and replace the ids with real addresses. The kernel should also check the buffers for other dangerous stuff. For what it's worth Microsoft seems to have a quite similar system in mind. http://download.microsoft.com/download/1/8/f/18f8cee2-0b64-41f2-893d-a6f2295b40c8/DW04018_WINHEC2004.ppt One clever thing they are doing is using the GART dynamically for swapping out video memory. > provide DRI contexts and help manage > them so multiple GL apps would work on all drivers (which, afaik, few if > any correctly support), and probably increase the over all quality of > all software. ? You can run multiple GL apps just fine. If it doesn't work it's a driver bug. -- Ville Syrjälä [EMAIL PROTECTED] http://www.sci.fi/~syrjala/ ------------------------------------------------------- This SF.Net email is sponsored by the new InstallShield X. >From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
