Discrepancy between what my application shows, and what the trace plays back (OpenGL)
Babis Koniaris
esrever2357 at gmail.com
Wed Aug 12 08:54:42 PDT 2015
Wow, that was quick and spot on :D
It was the state validation. I just added glValidateProgram() just after
glUseProgram() and the bug is magically gone in PC1, many thanks for that!
I still don't understand why a validation *check *would prevent the bug,
since I see no errors with glCheckError anyway.
Babis
On 12/08/2015 16:35, José Fonseca wrote:
> I see two possibilities:
>
> - one is that the bug in PC1 OpenGL driver is a race condition,
> enabling debug checking changes the timing, hence makes things pass
>
> - 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.
>
> I've seen this happening once.
>
> If this is the case, then this apitrace patch might get PC1 to draw
> correctly even when not checking errors not selected:
>
> diff --git a/retrace/glretrace.py b/retrace/glretrace.py
> index 1e19473..a863c3c 100644
> --- a/retrace/glretrace.py
> +++ b/retrace/glretrace.py
> @@ -280,7 +280,7 @@ class GlRetracer(Retracer):
> is_draw_arrays or \
> is_draw_elements or \
> function.name.startswith('glBeginTransformFeedback'):
> - print r' if (retrace::debug) {'
> + print r' if (1 || retrace::debug) {'
> print r' _validateActiveProgram(call);'
> print r' }'
>
> @@ -571,7 +571,7 @@ _getActiveProgram(void)
> static void
> _validateActiveProgram(trace::Call &call)
> {
> - assert(retrace::debug);
> + //assert(retrace::debug);
>
> glretrace::Context *currentContext = glretrace::getCurrentContext();
> if (!currentContext ||
>
>
>
> Jose
>
> On Wed, Aug 12, 2015 at 2:38 PM, Babis Koniaris <esrever2357 at gmail.com
> <mailto:esrever2357 at gmail.com>> wrote:
>
> Hi,
>
> 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.
>
> 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.
>
> I run qapitrace (latest version) and exit the application after a
> while, all while seeing the problem. I hit replay, and *the trace
> plays correctly, as in PC0. *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.
>
> What could be going on?
>
> Thanks,
> Babis
>
> _______________________________________________
> apitrace mailing list
> apitrace at lists.freedesktop.org <mailto:apitrace at lists.freedesktop.org>
> http://lists.freedesktop.org/mailman/listinfo/apitrace
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20150812/0f6672ec/attachment.html>
More information about the apitrace
mailing list