[Mesa-dev] [Bug 102241] gallium/wgl: SwapBuffers freezing regularly with swap interval enabled

[bugzilla-daemon at freedesktop.org]

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

            Bug ID: 102241
           Summary: gallium/wgl: SwapBuffers freezing regularly with swap
                    interval enabled
           Product: Mesa
           Version: 17.1
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Other
          Assignee: mesa-dev at lists.freedesktop.org
          Reporter: frank.richter at gmail.com
        QA Contact: mesa-dev at lists.freedesktop.org

Created attachment 133536
  --> https://bugs.freedesktop.org/attachment.cgi?id=133536&action=edit
Check for negative time stamp difference in wait_swap_interval()

If swap interval is enabled the gallium/wgl SwapBuffers may freeze up if
os_time_get_nano() happens to return a time stamp smaller than the last
requested.

wait_swap_interval() does only check for a time stamp difference smaller than
the 'swap period', but does not check for a negative difference. If that occurs
it may continue passing a negative sleep duration to os_time_sleep(), which
converts it to an unsigned DWORD, which may lead to very, very long sleep times
(perceived as the app being frozen).

However, due to the way os_time_get_nano() is implemented on Windows, the time
stamp going backwards may happen far more often than one would expect...
Doing a back-of-the-envelope calculation this can happens every 100 min or so:
* The time stamp is based on the "tick count" returned by
QueryPerformanceCounter(). It's a 64-bit value. so we have 1.84467*10^10
different possible values.
* However, the first step in os_time_get_nano() is to multiply the tick count
by 10^9, which may shift half of the digits out left, leaving us with
1.84467*10^10 different possible values.
* Next, that value is divided by the QPC frequency (ticks per second). On my
computer that's about 3*10^6 (I guess all modern systems have frequencies in
that ballpark), so our range of possible time stamp values covers ~6150
seconds... about 100 mins or so, after which we can expect the time stamp to
roll over!

Attached you can find patches to address these issues:
* A simple check in wait_swap_interval() to ignore negative time stamp
differences.
* A change of the way os_time_get_nano() converts ticks to nanoseconds that
avoids the initial multiplication with 10^9 potentially discarding half the
tick count digits.

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