<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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.<br>
<br>
Babis<br>
<br>
On 12/08/2015 16:35, José Fonseca wrote:<br>
</div>
<blockquote
cite="mid:CAH_+9jnQ_n=mJ9fUNdkTB-ysvEfonVMdScmcsid-nd4D2M8=Wg@mail.gmail.com"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:apitrace@lists.freedesktop.org">apitrace@lists.freedesktop.org</a><br>
<a moz-do-not-send="true"
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>
</body>
</html>