Keith Packard wrote: > On Thu, 2008-05-15 at 07:30 +0200, Thomas Hellström wrote: > > >> Static wc-d maps into fairly static objects like scanout buffers or >> buffer pools are not inefficient. They provide the by far highest >> throughput for writing (even beats cache-coherent). But they may take >> some time to set up or tear down, which means you should avoid that as >> much as possible. >> > > Yeah, the 2D driver uses the GTT mapping for drawing to the front > buffer. Otherwise, tiling is way too much work as the code isn't neatly > wrapped up like the Mesa swrast. For that, I just added detiling code. > > I'm not sure how I'd manage objects that can move or be evicted though; > perhaps some page table tricks could be used to avoid locking objects to > the GTT in a way visible to the user application. >
Yes, TTM does this by killing user-space mappings when an object is evicted. When they are again accessed by the app, they are simply faulted back mapping the new location wherever that is, changing caching policy if necessary. That approach is in principle reusable for a GEM implementation but I think not with the shmem backing objects, since we cannot overload the SHMEM fault() method, but that's only a limitiation of the current GEM implementation, not of the API design. One way to implement this in the GEM context I'd use the (small) part of drmBOs that deals with this, and use that as base GEM objects instead of SHMEMFS objects. Each GEM object would also always hold a page list. When the object has real pages attached to it (Like UMA objects) it would be populated with pages. When the object points to a place in VRAM, it holds swap_entry references (To reserve swap space used at suspend). If a GEM object, at creation, fails to allocate either pages or swap entries, object creation should fail to avoid failures later at unpredictable points. With this approach the GEM driver needs to decide when to push a GEM object's pages to the swap cache and when to reclaim them. It doesn't happen automatically as with the SMEMFS objects, but OTOH that puts the GEM driver in control on how much memory it will pin. That will avoid bad SHMEMFS decisions. > > >> The current implementation of GEM that doesn't allow overloading of the >> core GEM functions blocked the possibility to set up such mappings. This >> is about to change, and I'm happy with that. >> > > The requirement is that GEM provide the interfaces used by drivers; if a > driver needs some new functionality, we'd naturally work out how to > incorporate that. Right now, our 3D drivers don't care about GTT maps, > but I suspect our 2D ones will as I don't really want to try to deal > with tiling from all of the X server drawing code. > > Sounds good to me. Modesetting people will also be happy. /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
