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. > 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. -- [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part
------------------------------------------------------------------------- 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
