Wayland generic dmabuf protocol

[Thomas Daede]

Why does the kernel need to be the arbiter for buffer content constraints?
Instead, can't the client program query each hardware device for its
capabilities and then settle on a buffer format in common itself?

That said, I am writing a kernel driver for a video decoder and was looking
for ways to pass frames in and out - and I was under the impression that
DMA buf was mostly an in kernel interface, with FD handles for passing them
between syscalls. There was no way to allocate a new dma-buf descriptor in
userspace yourself.
On Mon, 9 Jun 2014 12:23:18 +0100
Daniel Stone <daniel at fooishbar.org> wrote:

> Hi,
>
> On 9 June 2014 12:06, Pekka Paalanen <pekka.paalanen at collabora.co.uk>
wrote:
>
> > On Mon, 9 Jun 2014 11:00:04 +0200
> > Benjamin Gaignard <benjamin.gaignard at linaro.org> wrote:
> > > One of the main comment on the latest patches was that wl_dmabuf use
> > > DRM for buffer allocation.
> > > This appear to be an issue since wayland doesn't want to rely on one
> > > specific framework (DRM, or V4L2) for buffer allocation, so we have
> > > start working on a "central dmabuf allocation" on kernel side. The
> > > goal is provide some as generic as possible to make it acceptable by
> > > wayland.
> >
> > Why would Wayland need a central allocator for dmabuf?
> >
>
> I think you've just answered your own question further below:
>
>
> > > On my hardware the patches you have (+ this one on gstwaylandsink
> > > https://bugzilla.gnome.org/show_bug.cgi?id=711155) allow me to do zero
> > > copy between the hardware video decoder and the display engine. I
> > > don't have implemented GPU yet because my hardware is able to do
> > > compose few video overlays planes and it was enough for my tests.
> >
> > Right.
> >
> > What I have been thinking is, that the compositor must be able to use
> > the new wl_buffer and we need to guarantee that before-hand. If the
> > compositor fails to use a wl_buffer when the client has already
> > attached it to a wl_surface and it is time to repaint, it is too late
> > and the user will see a glitch. Recovering from that requires asking
> > the client to provide a new wl_buffer of a different kind, which might
> > take time. Or a very rude compositor would just send a protocol error,
> > and then we'd get bug reports like "the video player just disappears
> > when I try to play (and ps. I have an old kernel that doesn't support
> > importing whatever)".
> >
> > I believe we must allow the compositor to test the wl_buffer before it
> > is usable for the client. That is the reason for the roundtrippy design
> > of the below proposal.
> >
>
> A central allocator would solve these issues, by having everyone agree on
> the restrictions upfront, instead of working out which of the media decode
> engine, camera, GPU, or display controller is the lowest common
> denominator, and forcing all allocations through there.
>
> One such solution was discussed a while back WRT ION:
> https://lwn.net/Articles/565469/
>
> See the 'possible solutions' part for a way for people to agree on
> restrictions wrt tiling, stride, contiguousness, etc.

Hi,

that's an excellent article. I didn't know that delayed allocation of
dmabufs was not even possible yet, which would have allowed us to
not think about importing failures and simply let the client fall back
with "ok, don't use dmabuf with this particular device then".

What is the conclusion here?

Wayland protocol does not need to consider import failures at all, and
can simply punt those as protocol errors, which essentially kill the app
if they ever happen?

Do we need to wait for the central allocator in kernel to materialize
before we can design the protocol? Is it simply too early to try to do
it now?

Was the idea of dmabuf in-kernel constraint negotiation with delayed
allocation rejected in favour of a central allocator?

Will Intel, Nouveau and Radeon support the central allocator, or will
it remain for ARM-related devices only?


Thanks,
pq
_______________________________________________
wayland-devel mailing list
wayland-devel at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140609/ed335a18/attachment-0001.html>