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

[José Fonseca]

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>
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>
> 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
>> http://lists.freedesktop.org/mailman/listinfo/apitrace
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/apitrace/attachments/20150812/73498250/attachment.html>