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

[Babis Koniaris]

Thanks for the info! I'll possibly file it. You mean provide the .trace 
file? Would be much easier than repro code.

Babis

On 12/08/2015 20:42, José Fonseca wrote:
> 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.
>
> 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.
>
> 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.
>
> Jose
>
>
> On Wed, Aug 12, 2015 at 4:54 PM, Babis Koniaris <esrever2357 at gmail.com 
> <mailto:esrever2357 at gmail.com>> wrote:
>
>     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/20150813/bc60e9ef/attachment-0001.html>