Hi, On 10 November 2016 at 06:08, Jonas Ådahl <jad...@gmail.com> wrote: > On Mon, Oct 24, 2016 at 08:42:59PM +0100, Daniel Stone wrote: >> The intent of moving blocking from SwapBuffers to get_back_bo, was to >> avoid unnecessary triple-buffering by ensuring that the compositor had >> fully processed the previous frame before we started rendering. This >> means that the only time we would have to resort to triple-buffering >> would be when the buffer is directly scanned out, thus saving an extra >> buffer for composition anyway. >> >> The 'repaint window' changes introduced in Weston since then, however, >> have narrowed the window of time between the frame event being sent and >> the repaint loop needing to conclude, to 7ms by default, in order to >> reduce latency. This means however that blocking in get_back_bo gives a >> maximum of 7ms for the entire GL submission to begin and complete. >> >> Not only this, but if a client is using buffer_age to avoid full >> repaints, the buffer-age request will stall in get_back_bo until the >> frame callback completes, meaning that the client cannot even calculate >> the repaint area before the 7ms window. >> >> The combination of the two meant that WebKit-GTK+ was failing to >> achieve full framerate on a Minnowboard, due to spending a great deal of >> its time attempting to query the age of the next buffer before redraw. >> >> Revert to the previous behaviour of allowing rendering to begin but >> delaying SwapBuffers, unless and until we can find a more gentle >> behaviour. >> >> Signed-off-by: Daniel Stone <dani...@collabora.com> >> Cc: Neil Roberts <n...@linux.intel.com> >> Cc: Kristian Høgsberg <k...@bitplanet.net> > > The explanations sounds sane to me, and even though it's a revert, I > looked at the patch and it seems correct, so this is > > Reviewed-by: Jonas Ådahl <jad...@gmail.com> > > I suspect we can't avoid tripple buffering if the client asks for > information about the next buffer early enough, since mesa won't have a > clue what the future will be regarding any buffer being released or not > before the frame callback.
Thanks both for the review/testing - pushed now. > Or maybe we could possibly fake the buffer age, pretending the buffer is > a fresh one if the client queries "too early", but then eventually > re-use the buffer had it been released before the frame callback. We'd > at least avoid the extra buffer being allocated, while instead only > wasting resources painting the whole buffer which we would do anyway if > we allocated the third buffer. That relies on the compositor releasing buffers in a strictly FIFO manner though, which is ... dangerous. If you're interested in buffer age though, here's another one: https://lists.freedesktop.org/archives/mesa-dev/2016-November/134787.html Cheers, Daniel _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev