[Intel-gfx] [PATCH] drm/i915: Introduce a new create ioctl for user specified placement

[Daniel Vetter]

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