From: Ville <sy...@sc...> - 2004-06-05 09:21:39
|
On Sat, Jun 05, 2004 at 03:09:54AM -0400, Patrick McFarland wrote: >=20 > 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. >=20 > Currently, projects such as DirectFB suffer because there is really no > unified method to do this. DirectFB nor xservers should ever be managin= g > 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. >=20 > 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= =20 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=20 interface would be simply one accepting almost complete DMA buffers. The=20 only thing missing from these buffers would be real memory addresses. The= =20 client should just use a surface id (handed out by the memory allocator)=20 instead of a real address. The kernel would then check if the client is=20 allowed to use those surfaces and replace the ids with real addresses. Th= e=20 kernel should also check the buffers for other dangerous stuff. For what it's worth Microsoft seems to have a quite similar system in=20 mind. http://download.microsoft.com/download/1/8/f/18f8cee2-0b64-41f2-893= d-a6f2295b40c8/DW04018_WINHEC2004.ppt One clever thing they are doing is using the GART dynamically for swappin= g=20 out video memory. > provide DRI contexts and help manage > them so multiple GL apps would work on all drivers (which, afaik, few i= f > 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 drive= r=20 bug. --=20 Ville Syrj=E4l=E4 sy...@sc... http://www.sci.fi/~syrjala/ |