[PATCH weston v2 1/8] protocol: add linux_dmabuf extension (v2)

[Daniel Stone]

Hi,

On 8 July 2015 at 09:02, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Wed, Jul 01, 2015 at 05:56:13PM +0300, Pekka Paalanen wrote:
>> From: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
>> +      - Make platform-specific call to ensure that caches are flushed, such
>> +        that access with GPU / display controller / CPU will be coherent, if
>> +        read-side caches are flushed on those devices (which is explicitly
>> +        the compositor's responsibility).
>
> and I don't understand this really. Currently the dma-buf design is that
> coherency is managed in the kernel, as long as you don't play tricks (like
> what mesa might internally do for partial uploads). That will also extend
> to a dma-buf mmap extension where we'll add explicit begin/end_cpu_access
> ioctls for cpu-side access. If you really want to talk about coherency I'd
> go with:
>
>         - clients must ensure that either all data in the dma-buf is
>           coherent for all subsequent read access or that coherency is
>           correctly handled by the underlying kernel-side dma-buf
>           implementation.
>
> Or just list this as an open issue. With that addressed this is

Yeah, I kind of tripped over my own feet there. I meant for it to be
about fencing, given that we don't accept dmabuf fences; so we can
drop the language around caches and go with what you have. Then we
could accept fences in a future version, when we have a better
testbed. I'm happy with that language - thanks!

Cheers,
Daniel