[Bug 711155] wayland: add wl_drm support to wayland sink

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=711155

--- Comment #62 from George Kiagiadakis <george.kiagiadakis at collabora.com> ---
(In reply to Daniel Stone from comment #61)
> (In reply to George Kiagiadakis from comment #60)

[...]

> > Dumb buffers are in a different memory and are cross-GPU compatible.
> 
> No, that's not it. Often they're in the same memory! It's every bit as
> possible to use buffers allocated through device-specific API as it is dumb
> buffers. In fact, sometimes even more possible.
> 
> The difference between dumb and non-dumb buffers is that dumb buffers are
> designed for exactly one usecase: software rendering into them whilst
> mmap()ed. You are guaranteed to be allowed to be able to mmap() dumb
> buffers, but this is explicitly _not_ true of non-dumb buffers, and there is
> no generic API provided for doing so. Similarly, non-dumb buffers can be
> used with hardware acceleration engines (mainly GPU), whereas dumb buffers
> are _explicitly_ not supported for hardware rendering. There are myriad
> reasons for this, frequently to do with coherency (not just pipeline/cache
> coherency, but also things like compression buffers); some of these are less
> valid today than they were when this was created, but not all.
> 
> tl;dr: the main difference is mmap

Ok, sorry, documentation about all this is totally confusing. Thanks for
clarifying.

> > What I would propose there is to keep wldmabufsink without any allocator and
> > instead require the use of "upload" elements, like inteldmabufupload. We can
> > have dumbdmabufupload, intel*, radeon*, nouveau*, ion*, whatever, if there
> > are use cases for them. Wayland does not really require any specific
> > allocator, it is up to the negotiation mechanism to decide what to use.
> 
> So the 'upload' element is essentially an allocator, right? In that it will
> control allocation of the storage backing the dmabuf in the first place,
> mediate access to it (e.g. performing any necessary pipeline/cache coherency
> calls), and provide (emulation of) CPU mapping if necessary.

Yes, the upload element will essentially provide an allocator to the pipeline
and also in the very very worst case that we have an upstream element that
doesn't know how to properly use allocators and buffer pools, it will copy over
buffer contents from other memory to the mmap()'ed dmabuf memory.

The rest (access mediation, mmap()ing, etc...) is controlled by the
superclasses of gstreamer already (GstMemory / GstAllocator / GstBufferPool).
The element's allocator will just implement the alloc() and free() functions.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.