Discrepancy between what my application shows, and what the trace plays back (OpenGL)
Mark Janes
mark.a.janes at intel.com
Wed Aug 12 12:01:08 PDT 2015
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
More information about the apitrace
mailing list