On Wed, Aug 26, 2015 at 08:49:00AM +0200, Thomas Hellstrom wrote: > Hi, Tiago. > > On 08/26/2015 02:02 AM, Tiago Vignatti wrote: > > From: Daniel Vetter <daniel.vet...@ffwll.ch> > > > > The userspace might need some sort of cache coherency management e.g. when > > CPU > > and GPU domains are being accessed through dma-buf at the same time. To > > circumvent this problem there are begin/end coherency markers, that forward > > directly to existing dma-buf device drivers vfunc hooks. Userspace can make > > use > > of those markers through the DMA_BUF_IOCTL_SYNC ioctl. The sequence would be > > used like following: > > > > - mmap dma-buf fd > > - for each drawing/upload cycle in CPU > > 1. SYNC_START ioctl > > 2. read/write to mmap area or a 2d sub-region of it > > 3. SYNC_END ioctl. > > - munamp once you don't need the buffer any more > > > > v2 (Tiago): Fix header file type names (u64 -> __u64) > > v3 (Tiago): Add documentation. Use enum dma_buf_sync_flags to the begin/end > > dma-buf functions. Check for overflows in start/length. > > v4 (Tiago): use 2d regions for sync. > > Daniel V had issues with the sync argument proposed by Daniel S. I'm > fine with that argument or an argument containing only a single sync > rect. I'm not sure whether Daniel V will find it easier to accept only a > single sync rect...
I'm kinda against all the 2d rect sync proposals ;-) At least for the current stuff it's all about linear subranges afaik, and even there we don't bother with flushing them precisely right now. My expectation would be that if you _really_ want to etch out that last bit of performance with a list of 2d sync ranges then probably you want to do the cpu cache flushing in userspace anyway, with 100% machine-specific trickery. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
