Op 30-07-13 10:13, Chris Wilson schreef: > On Tue, Jul 30, 2013 at 03:04:22PM +1000, Dave Airlie wrote: >> Hey, >> >> so I put a patch into intel driver a while ago to avoid doing a bo >> flush using map/unmap for output slave device if the kernel has vmap >> flushing >> >> However on reflection I realised this only works for CPU accessing >> devices like UDL but doesn't work for GPU accessing devices like >> nouveau/radeon, >> >> Going forward I'm sure we'll eventually get GPU sync via Maarten's >> patches but I'm thinking I should revert this change in the intel >> driver for now, >> so reverse optimus can work properly >> >> Anyone got any ideas for a better plan going forward, maybe a stop gap >> before Maartens patches. > I don't think it is possible to w/a this in userspace, so let's blame > Daniel^WBen for this mess and cheer on our knight in shining armour. > Go Maarten! But we need to be sure there is a similar synchronisation > point for CPU access to a foriegn dma-buf. > -Chris > It's complicated, and probably best suited to discuss at linux plumbers. :) It probably won't work without changing how the dma-buf locking is done, and for intel also depends on proper ww_mutex support. I think using reservation objects and fences in intel is the right way to go, and would allow for a less invasive integration of synchronization. In my experimental tree I used a hack in the execbuffer before to reserve all bo's, but the approach I took was rather hacky, and only applied to dma-bufs. Correct handling is probably better done by someone who understands i915 better than me. ~Maarten _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
