dmabuf modifiers for HW overlays

[Pekka Paalanen]

On Fri, 2 Aug 2019 12:19:52 +0200
Martin Stransky <stransky at redhat.com> wrote:

> On 8/2/19 12:04 PM, Martin Stransky wrote:
> >>> Also I wonder if it's feasible to use any modifiers as I need
> >>> plain/linear buffer to draw into by skia. I suspect when I create the
> >>> buffer with modifiers and then I map it to CPU memory for SW drawing,
> >>> intermediate buffer is created and then the pixels are de-composed back
> >>> to GPU memory.  
> >>
> >> No, I don't believe there is any kind of intermediate buffer behind the
> >> scenes in GBM or dmabuf ioctls/mmap. OpenGL drivers may use
> >> intermediate buffers. Some EGLImage operations are allowed to create
> >> more buffers behind the scenes but I think implementations try to avoid
> >> it. Copies are bad for performance, and implicit copies are unexpected
> >> performance bottle-necks. So yes, I believe you very much need to
> >> ensure the buffer gets allocated as linear from the start.
> >>
> >> Some hardware may have hardware tiling units, that may be able to
> >> represent a linear CPU view into a tiled buffer, but I know very little
> >> of that. I think they might need driver-specific ioctls to use or
> >> something, and are a scarce resource.  
> 
> The HW overlays is another use-case I'm working on. I want to draw 2D 
> data to dmabuf buffer by CPU and send it directly to GPU to render from 
> (bind as wl_buffer and attach it to wl_subsurface). I guess it also 
> depends on compositor how to handles that and how does that handle 
> mutter?. Does mutter such dmabuf buffer pass directly to GPU?

Hi Martin,

as far as I know, Mutter does texture directly from dmabuf wl_buffers.
Mutter has no support for hardware overlays yet.

> Also is it feasible to use *any* modifiers here and which flags should I 
> pass to gbm_bo_create()? I want to use plain DRM_FORMAT_ARGB8888 for the 
> dmabuf buffer as it's easy to draw into but I wonder if that buffer can 
> be used by GPU directly for compositing and how effective is that.

Hmm... I don't have any better information than you can find in gbm.h.

If you want the buffer to be possibly capable of direct scanout (to be
put on hardware overlay), use GBM_BO_USE_SCANOUT. Scanout-able memory
could be a relatively scarce resource though.

If you want the buffer to be linear for e.g. mmap purposes, use
GBM_BO_USE_LINEAR.

I don't think there is a flag for "use as a texture" since
GBM_BO_USE_RENDERING sounds more like use as a render target.

To know if a buffer can be textured from, you'll have to test importing
it into EGL and binding it as a GL texture.


However, zero-copy is not always a guaranteed performance win. It
usually is, but there can be cases where doing a copy is actually
faster than not copying. Just because zero-copy works does not mean it
is more efficient. I haven't observed it myself yet, but driver
developers have warned me about it.


Btw. if you happen to be able to use a hardware video decoder via V4L2,
that may already be able to produce dmabufs, which in the luckiest case
are also good for GL texturing if not even for scanout.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20190802/1e033ac2/attachment.sig>