Keith Packard wrote: > On Tue, 2008-03-04 at 17:34 +0100, Thomas Hellström wrote: > >> >> Hmm, Yes this is a tricky case. Doesn't Intel's coherent GART, >> DRM_BO_FLAG_CACHED, work here? I suspect it'd be a bit slow though. >> > > No, the restrictions on coherent mappings make this mode effectively > useless. So, pixmaps need to be mapped cached and explicit flushes > executed when moving between GPU and CPU. > Yes there are certainly restrictions, but at least the mode is usable for download-from-screen type of operations, so if we need to read from it during a composite operation it's possible to do:
1) malloc an image of the buffer. 2) Create a user-buffer using the malloced region. 3) Bind the user-buffer and do a blit copy. 4) Sync the blit. 5) Use the data. 6) If malloced image is dirty, CPU-copy back. Not sure how this will match current performance, though. > For transient data, using the GTT avoids chipset flushes, and also hits > a WC mapping so that we avoid CPU flushes. Just using WC mapping means > we still have to do chipset flushes, which doesn't seem useful to me. > You're right. Therefore using !DRM_BO_FLAG_CACHED on intel drm implies that attempts to map a bound buffer either from user-space or using drm_bo_kmap() will map its GTT image, not its underlying pages. If the buffer gets evicted during CPU-access, which is rare, the user-space mappings to the now stale GTT area are killed and have to be faulted back again to where the buffer is currently located. /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
