Sharing meta-data between DMA-BUF exporter and importer

[Daniel Stone]

Hi,


On 5 June 2014 07:49, Pekka Paalanen <ppaalanen at gmail.com> wrote:

> Then thinking about how that would work over a protocol like Wayland; A
> client is creating a buffer, and wants the compositor to present it,
> putting it on a hardware overlay if possible, or even scanning it
> out directly. We would like to know in advance what parameters are valid
> to avoid a roundtrip, but that's a lesser issue for now. We would need
> to be able to serialize the tiling definition to send it over the
> connection, and somehow negotiate a tiling that satisfies both sides.
>

I've had this in the back of my mind for a while, mostly for media usecases
where we'd like to promote things to an overlay if possible. For that, I
think a better fit would be a compositor -> client event (either in private
protocol, or in a generic one if we can get some kind of gralloc-style
cross-device usage flags standardised - there was something about this
posted which I'll try to dig up), where the client starts off allocating
normally without any specific knowledge of tiling, contiguous allocations,
stride limitations, etc.

When the compositor detects it could promote the client to an overlay but
couldn't, the private protocol would send a suggestion to the client that
it reallocate its buffers with a certain set of flags or constraints (e.g.
contiguous, pitch multiple of 4096, from a particular pool, etc) in order
to receive optimal treatment / avoid an intermediate blit.

We're missing one bit of compositor -> EGL API (i.e. inside
EGL_WL_bind_wayland_display) for this though, where the compositor could
inform EGL that a particular surface was a scanout candidate. But this
still requires knowledge inside the EGL stack of which surface a particular
buffer is targeted at (which wl_drm doesn't carry), and also how scanout
buffers need to be allocated (which, to be fair, gbm already needs to know).

Cheers,
Daniel

I'm not sure how feasible it would be for the compositor to tell the
> client which device it is going to use, so that the client could
> internally find a good tiling mode. It is also imaginable, that the
> compositor could be using multiple devices, and needs have the tiling
> fit for them all - or just fall back to requiring a tiling that works
> for the one GPU it is using for compositing and exclude the use of
> hardware overlays.
>
> Or maybe it could be other way: the client telling the compositor which
> device it wants to use to create buffer contents, and then the
> compositor replies with a suitable tiling format.
>
> What use cases would you like to cover? Only in-process negotiation
> between two devices so a compositor can show on one device what it
> renders on another, or also the display server vs. client negotiation?
>
>
> Thanks,
> pq
>
> > I'm adding Christian Gmeiner since I'm told he'll be likely needing
> > something similar for his work on etnaviv and it would be good to get a
> > second opinion on this.
> >
> > Thierry
> >
> > [0]: https://gitorious.org/thierryreding/kmscube
> > [1]:
> https://gitorious.org/thierryreding/kmscube/commit/b4d79d5c4e27b6d37234a137bdefc6ff517d6ea4
>
> _______________________________________________
> 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/20140605/2f0803b4/attachment.html>