Am 04.11.22 um 15:58 schrieb Rob Clark:
On Wed, Nov 2, 2022 at 5:21 AM Christian König
<ckoenig.leichtzumerken@xxxxxxxxx> 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
