<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Oct 30, 2013 at 3:59 AM, Tomeu Vizoso <span dir="ltr"><<a href="mailto:tomeu@tomeuvizoso.net" target="_blank">tomeu@tomeuvizoso.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 30 October 2013 09:44, Neil Roberts <<a href="mailto:neil@linux.intel.com">neil@linux.intel.com</a>> wrote:<br>
> Tomeu Vizoso <<a href="mailto:tomeu@tomeuvizoso.net">tomeu@tomeuvizoso.net</a>> writes:<br>
><br>
>> What I fail to see is why a single sync should be enough, as we don't<br>
>> know when the GPU will signal that it's done with the buffer that we<br>
>> are waiting to be released.<br>
><br>
> You are right that we don't know when the GPU will release the buffer.<br>
> However we are not waiting for that.<br>
<br>
</div>Oh, sure, was saying that in the context of the RPi, there we don't<br>
want the client to have to create more than 2 buffers per surface.<br>
<br>
In that EGL, SwapBuffers blocks waiting for the GPU to signal that<br>
it's done rendering with the buffer that is to become the back buffer.<br>
With your patch for not queueing if no frame callbacks are installed,<br>
we don't need to send any sync requests. Without it, we would need to<br>
keep syncing until we get the release.<br>
<br>
I know that you have dealt with it in Mesa already but wanted to reply<br>
to Jason's comment, sorry for hijacking your thread :)<br>
<br>
This is the relevant part of the code:<br>
<br>
<a href="https://github.com/tomeuv/userland/commit/a4a7cb233af5e5b167a1cb6f928b7a6381380a56#diff-b1115e30ce4f2940df2cd98a85009ccaR2339" target="_blank">https://github.com/tomeuv/userland/commit/a4a7cb233af5e5b167a1cb6f928b7a6381380a56#diff-b1115e30ce4f2940df2cd98a85009ccaR2339</a><br>
</blockquote><div><br></div><div>Ok, you are in the crazy edge-case that I feared. However, I still don't think we need some buffer release protocol. Since the buffer releasing issues are graphics-stack-dependent, shouldn't we push that off to the graphics-stack-dependent backends? I've attached a patch that provides a hook to let a component specify how it wants a given buffer to be released when it deferences it. Since RPi always wants its buffers back ASAP, the compositor can simply always post the event instead of queue. I'm going to reply to this e-mail with a patch that does just that.<br>
<br></div><div>If you're concerned with the case where the buffer release would otherwise get flushed by a frame but no frame events (or other events for that matter) are coming to the client, then I would consider that a weston bug. We should really find a way to ensure that buffers do get flushed eventually so clients don't starve(maybe once per frame).<br>
<br></div><div>I'm open to the possibility that this is a really bad idea. However, it seems more sane than an extra request or extra EGL extensions.<br></div><div>--Jason Ekstrand</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards,<br>
<br>
Tomeu<br>
<div class="HOEnZb"><div class="h5"><br>
> We are assuming that the GPU is<br>
> only going to hold on to at most 2 buffers. In the DRM / Mesa case it<br>
> needs to hold on to these because one will be used for scanout and one<br>
> will be queued for the page flip. If we attach a third buffer then it<br>
> will be held by the compositor as a queue for the next flip. We are<br>
> assuming it won't have given this buffer to the GPU. Therefore if we<br>
> attach a fourth buffer it is easy for the compositor to immediately<br>
> release its lock on the third buffer and replace it with the fourth. So<br>
> we can assume that the fourth attach will always generate an immediate<br>
> release event. Sending a sync request will ensure that we always get<br>
> this release event. So if we have four buffer slots we can assume that<br>
> one of the attaches will always generate an immediate release event.<br>
><br>
> In the non-fullscreen case where we don't really need to wait for the<br>
> GPU, we only need 2 slots because the compositor will only lock one<br>
> buffer.<br>
><br>
> Regards,<br>
> - Neil<br>
</div></div></blockquote></div><br></div></div>