Transform feedback counter not properly reset

[GoogleCodeExporter]

Hi,

A short example:
Create a transform feedback buffer;
Set the internal transform feedback counter to zero with glBindBufferRange;
Draw a primitive;
Set the counter back to zero with glBindBufferRange;
At this point ANGLE should reset the internal counter to zero for the next draw 
call.
Draw a primitive.
You should expect ANGLE to overwrite the first primitive with the second 
primitive inside the feedback buffer.

However ANGLE currently append the second primitive after the first primitive.

The problem is that ANGLE considers that if the offset has not changed between 
two draw calls then we should append to the buffer. On the second call to 
glBindBufferRange, the offset is still zero even though the counter used 
internally by the GPU has been incremented and after glBindBufferRange, the 
offset is still zero. In ANGLE, glBindBufferRange is a no-op if the offset is 
set to the same value as before.

I am aware of two possible solutions:
* Set the offset to -1 in the state vector after each draw call and assume that 
-1 means "append";
* Invalidate the applied offset when glBindBufferRange/Base is called.

I am not quite sure which one is the best. I like the first solution but it 
involves removing the const-ref from the state pointer in a lot of places.

Original issue reported on code.google.com by Gregory....@imgtec.com on 27 Jan 2015 at 6:48

[GoogleCodeExporter]

https://chromium-review.googlesource.com/#/c/243892/2

Original comment by Gregory....@imgtec.com on 28 Jan 2015 at 4:13

[GoogleCodeExporter]

Original comment by geofflang@chromium.org on 29 Apr 2015 at 7:19

• Changed state: Fixed

[GoogleCodeExporter]

Project: angle/angle
Branch : master
Author : Geoff Lang <geofflang@chromium.org>
Commit : 942e36254a1e3537371c39f3f23d1ce12f4c87e8

Code-Review  0 : Geoff Lang
Code-Review  +1: Zhenyao Mo
Code-Review  +2: Jamie Madill
Verified     0 : Jamie Madill, Zhenyao Mo
Verified     +1: Geoff Lang
Commit Queue   : Chumped
Change-Id      : I77054d04c9935eedcdbb7304dc0c3b60b53994f9
Reviewed-at    : https://chromium-review.googlesource.com/268434

Don't mark all macros with double underscores as reserved.

Only __FILE__, __LINE__, __VERSION__ and GL_ES are reserved but it is
still not recommended to use a name with double underscores because it may
be used by the "underlying software layers".

Updated the tests to reflect that it is OK to define macros with double
underscores but it is not valid to make assumptions about their values.

Fixes:
dEQP-GLES2.functional.shaders.preprocessor.basic.identifier_with_double_undersco
re_vertex
dEQP-GLES2.functional.shaders.preprocessor.basic.identifier_with_double_undersco
re_fragment

BUG=angleproject:898

src/compiler/preprocessor/DirectiveParser.cpp
src/tests/preprocessor_tests/define_test.cpp

Original comment by bugdroid1@chromium.org on 1 May 2015 at 2:32