tree cf8f1c8d8934fa9b843288d82663431cef918739
parent bfc5df1663c06744bf500ae8b8dfd2343e3e8471
author shrekshao <shrekshao@google.com> 1554423198 -0700
committer Commit Bot <commit-bot@chromium.org> 1554753950 +0000

Fix formsRenderingFeedbackLoopWith check

To make it pass the following webgl conformance test
https://github.com/KhronosGroup/WebGL/blob/master/sdk/tests/conformance/rendering/rendering-sampling-feedback-loop.html

It used to fail due to
1. Didn't check if texture unit is sampler complete
2. Only checked active drawbuffers. But drawbuffer settings shouldn't be
taken into account when checking drawing feedback loop.

On top of applying these 2 functional fixes, I also tried to do some
optimization by unwrapping the nested for loop for program sampler
bindings and texture unit in `Program::samplesFromTexture` and putting
them outside of the draw buffer loop according to the old comment by
Antonie @piman.
https://codereview.chromium.org/2461973002/

> ... turning it around (for each texture check if it's
also an attachment, instead of for each attachment check if it's a bound
texture). In particular, we have an upper bound on the number of
attachments, so we can look them up outside the loop into a fixed size
buffer on the stack - and the very common case will be to only have 1 of
them making the inner loop cheap.

But this unwraps sort of breaks the code structure. An alternative way
would be passed in a framebuffer pointer into `Program::samplesFromTexture`
but that would ends up in tight class coupling. I am a bit unsure here.
Would like to hear if think this change is okay in terms of code style.

In addition to further speed up this check (as it runs for every draw
validation) I added a cache mLastColorAttachmentId indicating the last i
of GL_COLORATTACHMENTi that is not GL_NONE to shorten this inner loop.
In most scenario we won't have up to max number of color attachments.

A side note: this is still failing
https://github.com/KhronosGroup/WebGL/blob/master/sdk/tests/conformance2/rendering/depth-stencil-feedback-loop.html
But it's because the test case doesn't fit the spec at this moment.
I will update this test later.

Bug: chromium:660844
Change-Id: I6d718dada71a5d989caac04de03f2454f2377612
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/1553963
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shrek Shao <shrekshao@google.com>