External DMA to gpu
ppaalanen at gmail.com
Wed Sep 12 09:21:22 UTC 2018
On Wed, 12 Sep 2018 08:30:55 +0200
Dirk Eibach <dirk.eibach at googlemail.com> wrote:
> Hi Pekka,
> > that would not involve Weston in any special way at all. Buffer
> > allocation is usually done in the client any way the client wants. To
> > ensure the buffer can be used by the compositor before you fill it with
> > data, you would export your buffer as a dmabuf and use
> > zwp_linux_dmabuf_v1 extension to send the buffer details to the Wayland
> > compositor. If that succeeds, all is good and you can fill the buffer.
> > After that, you have a wl_buffer you can attach to a wl_surface, and
> > the compositor will just process it, even put it on a DRM plane
> > bypassing compositing if possible.
> Thank you so much, that is exactly the information I needed.
> Is the simple-dmabuf-v4l client an implementation of this principle?
> So v4l2 offers an interface for passing the dmabuf. A v4l2 driver
> would probably the right choice for my grabber anyway.
yes, simple-dmabuf-v4l does exactly what I wrote in the above quote.
However, it does not allocate from the GPU device or from the display
device. Instead, it allocates from the V4L2 device and hopes that the
compositor will be able to use the buffers. Quite likely the compositor
can use the buffer, but they might not be fit for direct scanout which
would mean that composite bypass is not possible in the compositor.
FWIW, there is no general solution to the buffer allocation problem
that would ensure the buffer is usable for all purposes you would hope
it to be. There is work going on though:
Until that materializes, programs need to be smart about how to
allocate and hope it will work.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 833 bytes
Desc: OpenPGP digital signature
More information about the wayland-devel