[PATCH] Revert "compositor: Queue buffer.release instead of sending immediately"

[Daniel Stone]

Hi,

On 11 September 2013 17:15, Kristian Høgsberg <hoegsberg at gmail.com> wrote:
> On Wed, Sep 11, 2013 at 02:54:47PM -0400, Daniel Stone wrote:
>> Yeah, this is good to me.  Media pipelines also really want release
>> events ASAP, so they can reuse hardware-decoder buffers.
>
> The problem is that this will introduce an immediate event back to the
> client after it's done rendering.  The goal is to be able to have the
> client render receive the frame event and input, update its state and
> render the next frame, attach and commit and then sleep until the next
> frame event.  Sending out the release event immediately will wake it
> up one more time.  Would it work it make mesa send a wl_display.sync
> request following the commit if swapinterval is 0?

Ugh ... given that release isn't (even close to) guaranteed to be
generated instantly, that means you'd just have to (periodically) spam
the server with syncs until you get your release.  The main case I'm
thinking of is external media decode engines, which (as with every
non-APU access on ARM) require physically-contiguous memory.  If you
have large enough input and output resolutions, you end up with very
few buffers and so recycling them quickly becomes pretty imperative in
order to keep your frame rate up.  If you don't deliver releases
quickly enough, sometimes you end up losing frames as the decoder gets
totally starved.

Surely you'd have the same issue on 3D rendering with complex scenes
(which, given the lamentable state of memory bandwidth on some
devices, can equate to 'uses texturing') too, unless (at least)
triple-buffering ... ?

Cheers,
Daniel