<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Priority</th>
<td>medium
</td>
</tr>
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - i965: glGetGraphicsResetStatusARB always returns *RESET* status and never NO_ERROR"
href="https://bugs.freedesktop.org/show_bug.cgi?id=78769">78769</a>
</td>
</tr>
<tr>
<th>Assignee</th>
<td>idr@freedesktop.org
</td>
</tr>
<tr>
<th>Summary</th>
<td>i965: glGetGraphicsResetStatusARB always returns *RESET* status and never NO_ERROR
</td>
</tr>
<tr>
<th>QA Contact</th>
<td>intel-3d-bugs@lists.freedesktop.org
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux (All)
</td>
</tr>
<tr>
<th>Reporter</th>
<td>pavel.e.popov@intel.com
</td>
</tr>
<tr>
<th>Hardware</th>
<td>x86-64 (AMD64)
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Version</th>
<td>10.1
</td>
</tr>
<tr>
<th>Component</th>
<td>Drivers/DRI/i965
</td>
</tr>
<tr>
<th>Product</th>
<td>Mesa
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=99138" name="attach_99138" title="Initial patch to resolve this issue">attachment 99138</a> <a href="attachment.cgi?id=99138&action=edit" title="Initial patch to resolve this issue">[details]</a></span>
Initial patch to resolve this issue
Overview:
=========
The glGetGraphicsResetStatusARB from ARB_robustness extension always returns
GUILTY_CONTEXT_RESET_ARB and never returns NO_ERROR for guilty context with
LOSE_CONTEXT_ON_RESET_ARB strategy.
This is because Mesa returns GUILTY_CONTEXT_RESET_ARB if batch_active !=0
whereas kernel driver never reset batch_active and this variable always > 0 for
guilty context.
The same behaviour also can be observed for batch_pending and
INNOCENT_CONTEXT_RESET_ARB.
But spec says the following
(<a href="http://www.opengl.org/registry/specs/ARB/robustness.txt">http://www.opengl.org/registry/specs/ARB/robustness.txt</a>):
If a reset status other than NO_ERROR is returned and subsequent
calls return NO_ERROR, the context reset was encountered and
completed. If a reset status is repeatedly returned, the context may
be in the process of resetting.
8. How should the application react to a reset context event?
RESOLVED: For this extension, the application is expected to query
the reset status until NO_ERROR is returned. If a reset is encountered,
at least one *RESET* status will be returned. Once NO_ERROR is
encountered, the application can safely destroy the old context and
create a new one.
Reproducer:
===========
1. Create context with GL_LOSE_CONTEXT_ON_RESET_ARB strategy using
glXCreateContextAttribsARB().
2. Provoke hardware reset. For example using infinite shader.
3. Call glGetGraphicsResetStatusARB() in a loop.
4. Make sure that this function always returns GUILTY_CONTEXT_RESET_ARB. It's a
wrong behavior.
Solution:
=========
The main problem is the context may be in the process of resetting and in this
case a reset status should be repeatedly returned. But looks like the kernel
driver returns nonzero active/pending only if the context reset has already
been encountered and completed.
For this reason the *RESET* status cannot be repeatedly returned and should be
returned only once.
The reset_count and brw->reset_count variables can be used to control that
glGetGraphicsResetStatusARB returns *RESET* status only once for each context.
Note the i915 triggers reset_count twice which allows to return correct reset
count immediately after active/pending have been incremented.
The patch is attached.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>