On Tue, Jul 9, 2013 at 12:05 PM, Chris Wilson <chris at chris-wilson.co.uk> wrote: > On Tue, Jul 09, 2013 at 11:10:13AM +0200, Daniel Vetter wrote: >> One ugly part is that conceptually I think we want to support dma_buf >> exporting of stolen memory objects. After all exporting scanout buffers >> for rendering by the dgpu is the prime use-case of dma_buf. > > No. prime only exports an intermediate buffer, I don't see how you would > maintain coherency between the display engine and a foriegn GPU, given > the limited API. However fd passing remains a real issue. Do we not in > that case simply resolve the fd into a new handle onto the old bo and > discard the dma-buf? Phew we do, so that still works. The only case we > have to worry about is exporting stolen over dma-buf to a discrete GPU, > which will actually be rare and we could just forbid exporting the stolen > bo? Better to fix it up from the start though. Wrt scanout I'm thinking of exporting a yuv buffer from a separate camera pipe on an SoC. In such use-cases both devices can be told to dtrt with clflushed devices and so maintain coherency with the uncached scanout domain. But yeah, the real bummer is that as-is we don't support exporting stolen memory to a discrete gpu for rendering into due to the current shortcuts in the prime implementations we have in drm/*. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
