Hi, On 11 September 2013 17:15, Kristian Høgsberg <hoegsb...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel