<div dir="ltr">Hi,<div class="gmail_extra"><br><br><div class="gmail_quote">On 5 June 2014 07:49, Pekka Paalanen <span dir="ltr"><<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><span style="color:rgb(34,34,34)">Then thinking about how that would work over a protocol like Wayland; A</span><br>
</div></div>
client is creating a buffer, and wants the compositor to present it,<br>
putting it on a hardware overlay if possible, or even scanning it<br>
out directly. We would like to know in advance what parameters are valid<br>
to avoid a roundtrip, but that's a lesser issue for now. We would need<br>
to be able to serialize the tiling definition to send it over the<br>
connection, and somehow negotiate a tiling that satisfies both sides.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>Cheers,</div><div>Daniel</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm not sure how feasible it would be for the compositor to tell the<br>
client which device it is going to use, so that the client could<br>
internally find a good tiling mode. It is also imaginable, that the<br>
compositor could be using multiple devices, and needs have the tiling<br>
fit for them all - or just fall back to requiring a tiling that works<br>
for the one GPU it is using for compositing and exclude the use of<br>
hardware overlays.<br>
<br>
Or maybe it could be other way: the client telling the compositor which<br>
device it wants to use to create buffer contents, and then the<br>
compositor replies with a suitable tiling format.<br>
<br>
What use cases would you like to cover? Only in-process negotiation<br>
between two devices so a compositor can show on one device what it<br>
renders on another, or also the display server vs. client negotiation?<br>
<br>
<br>
Thanks,<br>
pq<br>
<div class=""><br>
> I'm adding Christian Gmeiner since I'm told he'll be likely needing<br>
> something similar for his work on etnaviv and it would be good to get a<br>
> second opinion on this.<br>
><br>
> Thierry<br>
><br>
> [0]: <a href="https://gitorious.org/thierryreding/kmscube" target="_blank">https://gitorious.org/thierryreding/kmscube</a><br>
> [1]: <a href="https://gitorious.org/thierryreding/kmscube/commit/b4d79d5c4e27b6d37234a137bdefc6ff517d6ea4" target="_blank">https://gitorious.org/thierryreding/kmscube/commit/b4d79d5c4e27b6d37234a137bdefc6ff517d6ea4</a><br>

<br>
</div>_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</blockquote></div><br></div></div>