Re: Try to address the DMA-buf coherency problem

["Christian König" <ckoenig.leichtzumerken@gmail.com>]

Am 04.11.22 um 15:58 schrieb Rob Clark:
> On Wed, Nov 2, 2022 at 5:21 AM Christian König
> <ckoenig.leichtzumerken@gmail.com> wrote:
>> Hi Lucas,
>>
>> Am 02.11.22 um 12:39 schrieb Lucas Stach:
>>> Hi Christian,
>>>
>>> going to reply in more detail when I have some more time, so just some
>>> quick thoughts for now.
>>>
>>> Am Mittwoch, dem 02.11.2022 um 12:18 +0100 schrieb Christian König:
>>>> Am 01.11.22 um 22:09 schrieb Nicolas Dufresne:
>>>>> [SNIP]
>>>> 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.
>>>>
>>>> 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.
>>>>
>>> With bracketed access you could even make this case work, as the dGPU
>>> would be able to slurp a copy of the dma-buf into LMEM for scanout.
>> Well, this copy is what we are trying to avoid here. The codec should
>> pump the data into LMEM in the first place.
>>
> For the dGPU VRAM case, shouldn't this be amdgpu re-importing it's own
> dmabuf, which more or less bypasses dma-buf to get back the backing
> GEM obj?

When the codec and scanout is on the same device, then yes.

But we already had cases where the codec was on the dGPU and scanout 
happened on the integrated engine.

Regards,
Christian.

>
> BR,
> -R