"Sottek, Matthew J" wrote: > > I posted a RFC about a new type of "Shared" agp memory a while back > but didn't get any input. I thought I would try again since there has > been better communication as of late, and the idea has progressed > somewhat. > > The problem: > The agpgart usage model is not well suited for UMA architectures because > each gart user is expected to allocate memory and only bind it into > the gart while it is active. Therefore on systems where all graphics > memory is obtained from the gart a huge amount of system memory is > wasted (16 Megs is probably a common amount of wasted memory on a > system running 2 X servers). To further the problem this memory is > non-swappable. > The issue has become exacerbated on embedded devices that must have > a framebuffer console for smooth graphics transitions during boot. > The framebuffer console must share a framebuffer among the virtual > terminals and eventually share resources with X. > > Solution: > I have created a new type of agp memory in use in the i810's agpgart. > This type is "Shared" memory and works quite differently from regular > agpgart memory. > First, when memory of type shared is allocated the allocation will > basically always succeed, but does not allocate any pages. It only > allocates the agp memory structure. The pages are only allocated when > bound. There is a shared reference count table (8bit * Number of pages) > that allows the agpgart driver to determine if the pages actually need > to be allocated at bind time. If a page is being bound where a > shared page already exists the reference count is increased and the > page is reused. Pages are freed when the last reference is removed > (during unbind)
This sounds like a clean approach to the problem. Unfortunately Jeff doesn't seem to be reading this group any more, so we can't get his comments, but this looks like a good solution to the problems of multiple distinct framebuffers chewing up memory on the i810 (and similar). Keith _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
