Try to address the DMA-buf coherency problem

[Christian König]

Am 02.11.22 um 13:19 schrieb Pekka Paalanen:
> On Wed, 2 Nov 2022 12:18:01 +0100
> Christian König <ckoenig.leichtzumerken at gmail.com> wrote:
>
>> Am 01.11.22 um 22:09 schrieb Nicolas Dufresne:
>>> [SNIP]
>>>>> But the client is just a video player. It doesn't understand how to
>>>>> allocate BOs for Panfrost or AMD or etnaviv. So without a universal
>>>>> allocator (again ...), 'just allocate on the GPU' isn't a useful
>>>>> response to the client.
>>>> Well exactly that's the point I'm raising: The client *must* understand
>>>> that!
>>>>
>>>> See we need to be able to handle all restrictions here, coherency of the
>>>> data is just one of them.
>>>>
>>>> For example the much more important question is the location of the data
>>>> and for this allocating from the V4L2 device is in most cases just not
>>>> going to fly.
>>> It feels like this is a generic statement and there is no reason it could not be
>>> the other way around.
>> And exactly that's my point. You always need to look at both ways to
>> share the buffer and can't assume that one will always work.
>>
>> As far as I can see it you guys just allocate a buffer from a V4L2
>> device, fill it with data and send it to Wayland for displaying.
>>
>> To be honest I'm really surprised that the Wayland guys hasn't pushed
>> back on this practice already.
> What should we Wayland people be pushing back on exactly? And where is
> our authority and opportunity to do so?
>
> The Wayland protocol dmabuf extension allows a graceful failure if the
> Wayland compositor cannot use the given dmabuf at all, giving the
> client an opportunity to try something else.

That's exactly what I meant with pushing back :)

I wasn't aware that this handling is already implemented.

> The Wayland protocol also
> tells clients which DRM rendering device at minimum the dmabuf needs to
> be compatible with. It even tells which KMS device the dmabuf could be
> put on direct scanout if the dmabuf was suitable for that and direct
> scanout is otherwise possible.

Yeah, perfect. Exactly that's what's needed here.

> What the client (application) does with all that information is up to
> the client. That code is not part of Wayland.
>
> I'm sure we would be happy to add protocol for anything that
> https://github.com/cubanismo/allocator needs to become the universal
> optimal buffer allocator library.

 From what you wrote it's already perfectly covered.

>> This only works because the Wayland as well as X display pipeline is
>> smart enough to insert an extra copy when it find that an imported
>> buffer can't be used as a framebuffer directly.
> The only fallback Wayland compositors tend to do is use OpenGL/Vulkan
> rendering for composition if direct scanout on a KMS plane does not
> work. There are many reasons why direct scanout may not be possible in
> addition to hardware and drivers not agreeing to do it with the given
> set of buffers.
>
> A general purpose (read: desktop) Wayland compositor simply cannot live
> without being able to fall back from KMS composition to software/GPU
> composition.
>
> But yes, there are use cases where that fallback is as good as failing
> completely. Those are not desktops but more like set-top-boxes and TVs.

Completely agree to this approach.

The only problem is that media players tend to not implement a way to 
allow direct scanout because of those fallback paths.

But as you said that's their decision.

Thanks,
Christian.

>
>
> Thanks,
> pq