On Mon, Feb 24, 2003 at 11:24:14AM -0800, Ian Romanick wrote: > 3.14 Interaction with XAA (open) > > What would be required to make the memory manager usable by the rest of > XFree86 for allocating pixmaps and the display buffer?
As i understand it, the interaction is not so much with XAA than with the Offscreen windows manager. Also there is the point of the framebuffers per se, and maybe we have to think about the RandR extension too. As it happens now (in 2D) the driver reserves some FB memory for the framebuffers, eventually splits the memory between both heads, and for the remaining memory, allocate some to the Off Screen Memory manager, and some for the DRI, right ? The framebuffer memory can be single buffered, but also dual buffered. This is currently set at configuration time, but one could guess that in the future we do dual buffering only when using using openGL windows, and be able to turn it on/off dynamically, and thus reclaim the memory for the second buffer. Also, with RandR, it is possible to change the size of the display, and maybe it would be possible to add the unused part to the Off Screen Memory manager, at least temporarily, but you would have to mark these sections as non pineable or something such, since you would need to reclaim them when switching back to the bigger display. Also, maybe it will be possible in the future to dynamically allocate a second head or something such. XAA and Xv use the offscreen memeory manager for their pixel cache and for storing the video image that is overlaid on the screen. The video overlay surface would be pinned while the video is playing, but the pixel cache can mostly be swapped out as needed. And you also have to reserve memory for the cursor overlay and maybe some for other internal usage (like using on card ring buffers). I hope i didn't foget anything. So basically, there are pinned memory areas (framebuffer and Xv overlay buffer) and other memory areas, which you can mostly handle the same as textures. That said, i guess we could simply reserve this memory early on in the driver initialization, one chunk for the framebuffer, another chunk for the OffScreen memory manager, and a third chunk for the Xv overlay. Then this memory would be marked as pinned, and you can pass it to the OffScreen memory manager without worrying about it, and it would be freed again when the we leave X or something such, and don't really need any changes in the current 2D drivers. That said, this would not help us to dynamically adjust the amount of memory allocated to 2D or 3D, it would be mostly the same as what is done today, and not very usefull. I need to look more at how the OffScreen memory manager works to say more, but my guess is that really using the new memory manager for 2D would mean rewriting an OS memory manager frontend to it, and have XAA and co use that. Also, you plan to write a small userspace library that can be used by the DRI drivers to allocate memory. I suppose you don't want to copy this code one time for the DRI driver and one time for the 2D drivers, so it would be best if it was shareable. Finally, maybe you should give some thought also of people wanting to use the DRI together with the fbdev, or something such, and make the memory manager library also available to fbdev using apps or something such, haven't thought much about that though. Friendly, Sven Luther ------------------------------------------------------- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
