[Mesa-dev] [PATCH] Revert "wayland: Block for the frame callback in get_back_bo not dri2_swap_buffers"

Daniel Stone daniel at fooishbar.org
Mon Nov 21 15:56:54 UTC 2016


Hi Jonas,

On 21 November 2016 at 05:56, Jonas Ådahl <jadahl at gmail.com> wrote:
> On Thu, Nov 10, 2016 at 10:38:51AM +0000, Daniel Stone wrote:
>> On 10 November 2016 at 06:08, Jonas Ådahl <jadahl at gmail.com> wrote:
>> > On Mon, Oct 24, 2016 at 08:42:59PM +0100, Daniel Stone wrote:
>> That relies on the compositor releasing buffers in a strictly FIFO
>> manner though, which is ... dangerous.
>
> Is FIFO an issue here? Lets assume it looks like this:
>
> [...]
>
> In other terms, if we don't have a buffer released at the point we
> query, we say its a new buffer, making the application assume it needs
> to redraw everything. When we then actually need the buffer for doing
> things, we see if there is any buffer to reuse. What buffer was actually
> released doesn't matter, since the application will redraw everything
> anyway, and if we actually did reuse a buffer, the previously returned
> buffer age was a lie, but a harmless one, and if we eventually actually
> did allocate a new one, it wouldn't even be a lie.

Sorry, I see what you mean now - thanks for the snippet!

Yes, I think that's certainly doable; we could add a parameter to
get_back_bo controlling its wait behaviour. Specifically, when called
from query_buffer_age we would return a released buffer (if any), do
one roundtrip and check again if we didn't have one yet, and if the
roundtrip didn't return any buffers, then we could return an age of -1
to allow the client to continue on. When called from
get_buffers_with_format, it would spin or allocate a new buffer. I
suppose there is a degenerate case there, where you could end up
always failing the age check but not allocating new buffers, but I'm
far too Monday'ed to sketch out what that would be.

Cheers,
Daniel


More information about the mesa-dev mailing list