<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - gallium/wgl: SwapBuffers freezing regularly with swap interval enabled"
href="https://bugs.freedesktop.org/show_bug.cgi?id=102241">102241</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>gallium/wgl: SwapBuffers freezing regularly with swap interval enabled
</td>
</tr>
<tr>
<th>Product</th>
<td>Mesa
</td>
</tr>
<tr>
<th>Version</th>
<td>17.1
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Other
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Component</th>
<td>Other
</td>
</tr>
<tr>
<th>Assignee</th>
<td>mesa-dev@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>frank.richter@gmail.com
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>mesa-dev@lists.freedesktop.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=133536" name="attach_133536" title="Check for negative time stamp difference in wait_swap_interval()">attachment 133536</a> <a href="attachment.cgi?id=133536&action=edit" title="Check for negative time stamp difference in wait_swap_interval()">[details]</a></span> <a href='page.cgi?id=splinter.html&bug=102241&attachment=133536'>[review]</a>
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>