[Mesa-dev] [Bug 98833] [REGRESSION, bisected] Wayland revert commit breaks fullscreen frame updates

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=98833

            Bug ID: 98833
           Summary: [REGRESSION, bisected] Wayland revert commit breaks
                    fullscreen frame updates
           Product: Mesa
           Version: git
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: EGL/Wayland
          Assignee: wayland-bugs at lists.freedesktop.org
          Reporter: eero.t.tamminen at intel.com
        QA Contact: mesa-dev at lists.freedesktop.org

Most of SynMark2 v7.0.1 (internal test-suite) Wayland version tests' fullscreen
frame updates start to be shown in random order after following commit:
------------------
commit 9ca6711faa03a9527c0946f2489e42cd9a62235c
Author:     Daniel Stone <daniels at collabora.com>
AuthorDate: Wed Jun 1 09:59:06 2016 +0100
Commit:     Daniel Stone <daniels at collabora.com>
CommitDate: Thu Nov 10 10:25:03 2016 +0000

    Revert "wayland: Block for the frame callback in get_back_bo not
dri2_swap_buffers"

    This reverts commit 25cc889004aad6d1cab9edd76db898658e347b97, though
    since the code has changed, it was applied manually.

    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 <daniels at collabora.com>
    Reviewed-by: Jonas Ådahl <jadahl at gmail.com>
    Reviewed-by: Derek Foreman <derekf at osg.samsung.com>
    Tested-by: Derek Foreman <derekf at osg.samsung.com>
    Cc: Kristian Høgsberg <krh at bitplanet.net>
------------------

Frame updates work fine with 12.0.4 & 13.0.1 (and Ubuntu Mesa 11.2), but not
after above commit.

Test suite has options for using single, double or triple buffering and
toggling Vsync, but these didn't have any effect.

Only if the tests are run in non-native (fullscreen) resolution, or as
windowed, the problem isn't visible.

I wasn't able to reproduce the issue with (Ubuntu) Glmark2 Wayland version, and
didn't have any other test-cases at hand.

So far I've tested this only on SKL, with Ubuntu 16.04, using its default
kernel (i.e. don't know whether kernel affects it).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20161123/d0af14a4/attachment.html>