<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Thanks for the info! I'll possibly file
it. You mean provide the .trace file? Would be much easier than
repro code.<br>
<br>
Babis<br>
<br>
On 12/08/2015 20:42, José Fonseca wrote:<br>
</div>
<blockquote
cite="mid:CAH_+9jnpZgLZw2mKuZjHTmXyAV4otmY5iZNUYwDs8HF+KrfJnQ@mail.gmail.com"
type="cite">
<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
moz-do-not-send="true"
href="mailto:esrever2357@gmail.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:esrever2357@gmail.com">esrever2357@gmail.com</a></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
moz-do-not-send="true"
href="mailto:esrever2357@gmail.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:esrever2357@gmail.com">esrever2357@gmail.com</a></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"
target="_blank">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>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>