Keith Packard wrote: > On Fri, 2008-05-16 at 09:28 +0200, Thomas Hellström wrote: > >> Hi. >> >> I have a couple of question w r t the TTM vs GEM discussion: >> >> 2) Some people have stated that GPU page faults could not be implemented >> with TTM. >> We've certainly dealt with that type of hardware, but found no obvious >> reason to use that feature. >> > > It seems like it would be nicer to deal with memory on a page-by-page > basis; evicting pages instead of whole objects. It would require a page > table between GPU and vram to be useful, and then you still get to deal > with the GPU address space allocation adventure. >
I think this would help only to avoid fragmentation which shouldn't be a big issue either in GEM nor in TTM. Not that the simple mem-range allocator avoids fragmentation, but we have ways to deal with it. My feeling is that the penalty of keeping track of the completion and flush status of each page would outweigh the benefits, be it VRAM or translation-table memory. > >> Could someone tell me why this feature can't be used with TTM (or is it >> that it can't be used with the current TTM driver interface?) and also >> a typical use-case where it might be beneficial within either the GEM or >> TTM context? >> > > Certainly moving from object management to page management would > simplify handling of the GPU memory space, but I'm not sure how making > these objects demand-paged would help all that much. > > Me neither. /Thomas ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
