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

[Mark Janes]

Hi Babis,

>From your description, it sounds like you may have found a bug in Mesa.
Would you be willing to provide an apitrace file that exhibits the
behavior you describe below?

Also, it would provide the following details about PC1:

OS/Distribution version
mesa version
cpu model

If I can reproduce it, I'll write it up and try to get it addressed.  

Thanks,

Mark

Babis Koniaris <esrever2357 at gmail.com> writes:

> 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
>>
>>
>
> _______________________________________________
> apitrace mailing list
> apitrace at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/apitrace