Discrepancy between what my application shows, and what the trace plays back (OpenGL)

[Babis Koniaris]

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>