<div dir="ltr"><div>There are very few things done by glretrace when checking for errors that have side effects. glValidateProgram is one of them (or perhaps the only one): glValidateProgram forces the driver check all bound state -- compile shader variants attending the current state, etc -- pretty much as if doing a draw call, but without the drawing.</div><div><br></div><div>It seems that PC1's OpenGL driver has some bug propagating/translating internal state, and that when it's done inside glValidateProgram it is avoided somehow.</div><div><br></div><div>I recommend you to file a bug against the OpenGL driver regardless -- even glValidateProgram worksaround the bug now there is no guarantee it will workaround the bug in the future. If you provide the trace and the information that glValidateProgram avoids the bug then it should be easy for the IHV to track down the bug.</div><div><br></div><div>Jose</div><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 12, 2015 at 4:54 PM, Babis Koniaris <span dir="ltr"><<a href="mailto:esrever2357@gmail.com" target="_blank">esrever2357@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Wow, that was quick and spot on :D <br>
It was the state validation. I just added glValidateProgram() just
after glUseProgram() and the bug is magically gone in PC1, many
thanks for that!<br>
I still don't understand why a validation <b>check </b>would
prevent the bug, since I see no errors with glCheckError anyway.<span class="HOEnZb"><font color="#888888"><br>
<br>
Babis</font></span><div><div class="h5"><br>
<br>
On 12/08/2015 16:35, José Fonseca wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>I see two possibilities:<br>
<br>
</div>
- one is that the bug in PC1 OpenGL driver is a race
condition, enabling debug checking changes the timing,
hence makes things pass<br>
<br>
</div>
- the other is that the bug is some sort of state validation
issue, and the glValidateProgram done by glretrace when
checking errors, avoids the bug.<br>
<br>
</div>
<div> I've seen this happening once.<br>
<br>
</div>
<div> If this is the case, then this apitrace patch might get
PC1 to draw correctly even when not checking errors not
selected:<br>
<br>
<span style="font-family:monospace,monospace">diff --git
a/retrace/glretrace.py b/retrace/glretrace.py<br>
index 1e19473..a863c3c 100644<br>
--- a/retrace/glretrace.py<br>
+++ b/retrace/glretrace.py<br>
@@ -280,7 +280,7 @@ class GlRetracer(Retracer):<br>
is_draw_arrays or \<br>
is_draw_elements or \<br>
function.name.startswith('glBeginTransformFeedback'):<br>
- print r' if (retrace::debug) {'<br>
+ print r' if (1 || retrace::debug) {'<br>
print r' _validateActiveProgram(call);'<br>
print r' }'<br>
<br>
@@ -571,7 +571,7 @@ _getActiveProgram(void)<br>
static void<br>
_validateActiveProgram(trace::Call &call)<br>
{<br>
- assert(retrace::debug);<br>
+ //assert(retrace::debug);<br>
<br>
glretrace::Context *currentContext =
glretrace::getCurrentContext();<br>
if (!currentContext ||<br>
<br>
</span><br>
<br>
</div>
Jose<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Aug 12, 2015 at 2:38 PM, Babis
Koniaris <span dir="ltr"><<a href="mailto:esrever2357@gmail.com" target="_blank">esrever2357@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Hi, <br>
<br>
I was looking onto a problem where my application displays
what I expect on one PC (PC0) and exhibits a bug on
another (PC1). PC0 has a nice powerful Geforce TITAN,
while PC1 is a laptop intel integrated card. I'm running
an application on OpenGL 4.00 (GLSL 4.00) which is
supported on both.<br>
<br>
The problem lies with reading the contents of a particular
texture (R16UI): on PC1 the shader always reads zeroes,
while on PC0 it reads the values normally. There are no
OpenGL errors. Here is when I decided to run apitrace to
find out what's going on.<br>
<br>
I run qapitrace (latest version) and exit the application
after a while, all while seeing the problem. I hit replay,
and <b>the trace plays correctly, as in PC0. </b>After a
bit of fiddling, I realized that if, in the Replay menu,
"Error Checking" is selected, then the trace plays
correctly as in PC0. If it's not selected, then it shows
the bug as usual. <br>
<br>
What could be going on?<br>
<br>
Thanks,<br>
Babis<br>
</div>
<br>
_______________________________________________<br>
apitrace mailing list<br>
<a href="mailto:apitrace@lists.freedesktop.org" target="_blank">apitrace@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/apitrace" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/apitrace</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div>