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? BR, -R
