On Tue, 2008-03-04 at 19:27 +0100, Thomas Hellström wrote: > 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.
The alternative you have with CACHED_MAPPED is: 1) Wait for any fence on the buffer. 2) Map buffer into kernel virtual (noop if direct map available) 3) clflush over the buffer 3) Unmap from kernel (also noop) 4) Map the buffer into userspace if it isn't (already done, so noop) Or, restated: 1) Wait for fence 2) clflush buffer 3) profit When we move to highmem, those kernel maps will actually start costing on i386, so we may decide at that point to let the userland code say "no, really, I'll flush that map through my own mapping of the buffer." as an optimization. Now, the point of using user-buffers is relevant to my interests. I'd love to be using user buffers in CACHED_MAPPED mode for the 3d driver, to avoid the mapping and kernel page allocation overhead by using the plain old libc allocator that already happily hangs on to mapped pages for me. It might obsolete my buffer-reuse branch. However, the DRM needs some fixes to allow this to happen. -- Eric Anholt [EMAIL PROTECTED] [EMAIL PROTECTED] [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
