Replace fWillReadFragmentPosition with a bitfield

Replace fWillReadFragmentPosition with a bitfield

Replaces fWillReadFragmentPosition on GrProcessor with a 
"RequiredFeatures" bitfield. This will allow us to add additional 
built-in features. Completely removes information about reading the
fragment position from GrPipeline and GrProcOptInfo.


BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1734163002

Committed: https://skia.googlesource.com/skia/+/87332103c605dc3e0f76c0d1250a76c4ff71fddc

[Chris Dalton, 2016-02-25 19:06:01]

Description was changed from

==========
Replace "willReadFragmentPosition" with a bitfield

Replaces uses of "willReadFragmentPosition" with a "BuiltInState"
bitfield. This will allow us to add additional built-in state.

BUG=skia:
==========

to

==========
Replace "willReadFragmentPosition" with a bitfield

Replaces uses of "willReadFragmentPosition" with a "BuiltInState"
bitfield. This will allow us to add additional built-in state.

BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

[Chris Dalton, 2016-02-25 19:06:50]

cdalton@nvidia.com changed reviewers:
+ bsalomon@google.com, joshualitt@google.com, robertphillips@google.com

[Chris Dalton, 2016-02-25 19:19:03]

https://codereview.chromium.org/1734163002/diff/1/src/gpu/GrProcOptInfo.cpp
File src/gpu/GrProcOptInfo.cpp (right):

https://codereview.chromium.org/1734163002/diff/1/src/gpu/GrProcOptInfo.cpp#n...
src/gpu/GrProcOptInfo.cpp:63: fBuiltInState = GrProcessor::kNone_BuiltInState;
FYI, this is bad news for a processor that modifies the sample mask. We will
need to come up with some way for these sample mask processors to indicate that
they have side effects and can't be removed.

[joshualitt, 2016-02-25 19:21:29]

https://codereview.chromium.org/1734163002/diff/1/include/gpu/GrProcessor.h
File include/gpu/GrProcessor.h (right):

https://codereview.chromium.org/1734163002/diff/1/include/gpu/GrProcessor.h#n...
include/gpu/GrProcessor.h:125: void enableBuiltInState(BuiltInState state) {
fBuiltInState |= state; }
This is more a question for Brian / Robert, but do we want to hide the fact that
the implementation is a bit field? I kind of like setWillReadFragmentPosition /
willReadFragmentPosition, though I also like that compose shader can just grab
the whole bitfield of its children.  Maybe retain the old willRead/setWillRead
calls, but also allow access to the BuiltInState enum?  I don't really have a
strong preference.

[Chris Dalton, 2016-02-25 19:45:30]

https://codereview.chromium.org/1734163002/diff/1/include/gpu/GrProcessor.h
File include/gpu/GrProcessor.h (right):

https://codereview.chromium.org/1734163002/diff/1/include/gpu/GrProcessor.h#n...
include/gpu/GrProcessor.h:125: void enableBuiltInState(BuiltInState state) {
fBuiltInState |= state; }
On 2016/02/25 19:21:29, joshualitt wrote:
> This is more a question for Brian / Robert, but do we want to hide the fact
that
> the implementation is a bit field? I kind of like setWillReadFragmentPosition
/
> willReadFragmentPosition, though I also like that compose shader can just grab
> the whole bitfield of its children.  Maybe retain the old willRead/setWillRead
> calls, but also allow access to the BuiltInState enum?  I don't really have a
> strong preference.

So, willRead isn't very needed anymore on this class. GrPipeline in this change
still keeps "willReadFragPosition", and that's where everybody else asks this
question AFAIK.

[Chris Dalton, 2016-02-25 20:38:37]

https://codereview.chromium.org/1734163002/diff/1/include/gpu/GrProcessor.h
File include/gpu/GrProcessor.h (right):

https://codereview.chromium.org/1734163002/diff/1/include/gpu/GrProcessor.h#n...
include/gpu/GrProcessor.h:125: void enableBuiltInState(BuiltInState state) {
fBuiltInState |= state; }
On 2016/02/25 19:45:30, Chris Dalton wrote:
> On 2016/02/25 19:21:29, joshualitt wrote:
> > This is more a question for Brian / Robert, but do we want to hide the fact
> that
> > the implementation is a bit field? I kind of like
setWillReadFragmentPosition
> /
> > willReadFragmentPosition, though I also like that compose shader can just
grab
> > the whole bitfield of its children.  Maybe retain the old
willRead/setWillRead
> > calls, but also allow access to the BuiltInState enum?  I don't really have
a
> > strong preference.
> 
> So, willRead isn't very needed anymore on this class. GrPipeline in this
change
> still keeps "willReadFragPosition", and that's where everybody else asks this
> question AFAIK.

Also, FWIW, this feels pretty similar to "fsBuilder->enableFeature(kMy_Feature)"

https://codereview.chromium.org/1734163002/diff/1/src/gpu/GrPipeline.cpp
File src/gpu/GrPipeline.cpp (right):

https://codereview.chromium.org/1734163002/diff/1/src/gpu/GrPipeline.cpp#newc...
src/gpu/GrPipeline.cpp:187: fBuiltInState = GrProcessor::kNone_BuiltInState;
We a problem here that fBuiltInState *should* intitialize with:

 fBuiltInState = GrPrimitiveProcessor.builtInState();

But I don't think the primitive processor is known yet at this point. Thoughts?
Otherwise if the primitive processor enables built in state, the pipeline won't
know about it.

[joshualitt, 2016-02-25 20:50:27]

https://codereview.chromium.org/1734163002/diff/1/src/gpu/GrPipeline.cpp
File src/gpu/GrPipeline.cpp (right):

https://codereview.chromium.org/1734163002/diff/1/src/gpu/GrPipeline.cpp#newc...
src/gpu/GrPipeline.cpp:187: fBuiltInState = GrProcessor::kNone_BuiltInState;
On 2016/02/25 20:38:37, Chris Dalton wrote:
> We a problem here that fBuiltInState *should* intitialize with:
> 
>  fBuiltInState = GrPrimitiveProcessor.builtInState();
> 
> But I don't think the primitive processor is known yet at this point.
Thoughts?
> Otherwise if the primitive processor enables built in state, the pipeline
won't
> know about it.
> 

That should be okay.  We never remove the primitive processor, and it will
always get a chance to modify the key / insert whatever code it wants.

https://codereview.chromium.org/1734163002/diff/1/src/gpu/GrProcOptInfo.cpp
File src/gpu/GrProcOptInfo.cpp (right):

https://codereview.chromium.org/1734163002/diff/1/src/gpu/GrProcOptInfo.cpp#n...
src/gpu/GrProcOptInfo.cpp:63: fBuiltInState = GrProcessor::kNone_BuiltInState;
On 2016/02/25 19:19:03, Chris Dalton wrote:
> FYI, this is bad news for a processor that modifies the sample mask. We will
> need to come up with some way for these sample mask processors to indicate
that
> they have side effects and can't be removed.

Yea, we don't actually remove processors from the coverage side of the pipeline,
so I think this isn't an issue, but it does seem fragile.

[Chris Dalton, 2016-02-25 20:57:46]

https://codereview.chromium.org/1734163002/diff/1/src/gpu/GrPipeline.cpp
File src/gpu/GrPipeline.cpp (right):

https://codereview.chromium.org/1734163002/diff/1/src/gpu/GrPipeline.cpp#newc...
src/gpu/GrPipeline.cpp:187: fBuiltInState = GrProcessor::kNone_BuiltInState;
On 2016/02/25 20:50:27, joshualitt wrote:
> On 2016/02/25 20:38:37, Chris Dalton wrote:
> > We a problem here that fBuiltInState *should* intitialize with:
> > 
> >  fBuiltInState = GrPrimitiveProcessor.builtInState();
> > 
> > But I don't think the primitive processor is known yet at this point.
> Thoughts?
> > Otherwise if the primitive processor enables built in state, the pipeline
> won't
> > know about it.
> > 
> 
> That should be okay.  We never remove the primitive processor, and it will
> always get a chance to modify the key / insert whatever code it wants. 

But the primitive processor might not exist yet, right?

[joshualitt, 2016-02-25 21:00:50]

https://codereview.chromium.org/1734163002/diff/1/src/gpu/GrPipeline.cpp
File src/gpu/GrPipeline.cpp (right):

https://codereview.chromium.org/1734163002/diff/1/src/gpu/GrPipeline.cpp#newc...
src/gpu/GrPipeline.cpp:187: fBuiltInState = GrProcessor::kNone_BuiltInState;
On 2016/02/25 20:57:46, Chris Dalton wrote:
> On 2016/02/25 20:50:27, joshualitt wrote:
> > On 2016/02/25 20:38:37, Chris Dalton wrote:
> > > We a problem here that fBuiltInState *should* intitialize with:
> > > 
> > >  fBuiltInState = GrPrimitiveProcessor.builtInState();
> > > 
> > > But I don't think the primitive processor is known yet at this point.
> > Thoughts?
> > > Otherwise if the primitive processor enables built in state, the pipeline
> > won't
> > > know about it.
> > > 
> > 
> > That should be okay.  We never remove the primitive processor, and it will
> > always get a chance to modify the key / insert whatever code it wants. 
> 
> But the primitive processor might not exist yet, right?

right, but that should be okay because when we go to flush the draw we'll have a
GrPrimitiveProcessor + GrPipeline combination and at that point the
GrPrimitiveProcessor can do whatever it wants, regardless of the builtinstate
values on the GrPipeline.

[bsalomon, 2016-02-25 21:11:03]

https://codereview.chromium.org/1734163002/diff/1/include/gpu/GrProcessor.h
File include/gpu/GrProcessor.h (right):

https://codereview.chromium.org/1734163002/diff/1/include/gpu/GrProcessor.h#n...
include/gpu/GrProcessor.h:125: void enableBuiltInState(BuiltInState state) {
fBuiltInState |= state; }
On 2016/02/25 20:38:37, Chris Dalton wrote:
> On 2016/02/25 19:45:30, Chris Dalton wrote:
> > On 2016/02/25 19:21:29, joshualitt wrote:
> > > This is more a question for Brian / Robert, but do we want to hide the
fact
> > that
> > > the implementation is a bit field? I kind of like
> setWillReadFragmentPosition
> > /
> > > willReadFragmentPosition, though I also like that compose shader can just
> grab
> > > the whole bitfield of its children.  Maybe retain the old
> willRead/setWillRead
> > > calls, but also allow access to the BuiltInState enum?  I don't really
have
> a
> > > strong preference.
> > 
> > So, willRead isn't very needed anymore on this class. GrPipeline in this
> change
> > still keeps "willReadFragPosition", and that's where everybody else asks
this
> > question AFAIK.
> 
> Also, FWIW, this feels pretty similar to
"fsBuilder->enableFeature(kMy_Feature)"

I find the setWillFoo() a bit more readable than enableFeature(kFoo). It doesn't
feel like these are inherently related, just happen to be sharing a bitfield for
implementation.

WRT children FPs, I really hope we replace the current mess of pulling state
into the parent with a system that iterates over the DAG externally.

https://codereview.chromium.org/1734163002/diff/1/src/gpu/GrProcOptInfo.cpp
File src/gpu/GrProcOptInfo.cpp (right):

https://codereview.chromium.org/1734163002/diff/1/src/gpu/GrProcOptInfo.cpp#n...
src/gpu/GrProcOptInfo.cpp:63: fBuiltInState = GrProcessor::kNone_BuiltInState;
On 2016/02/25 20:50:27, joshualitt wrote:
> On 2016/02/25 19:19:03, Chris Dalton wrote:
> > FYI, this is bad news for a processor that modifies the sample mask. We will
> > need to come up with some way for these sample mask processors to indicate
> that
> > they have side effects and can't be removed.
> 
> Yea, we don't actually remove processors from the coverage side of the
pipeline,
> so I think this isn't an issue, but it does seem fragile.

Yeah, querying willModifySampleMask could be the indicator.

[Chris Dalton, 2016-02-25 22:24:24]

Ok, I think patchset 2 addresses most the concerns that came up.

https://codereview.chromium.org/1734163002/diff/1/include/gpu/GrProcessor.h
File include/gpu/GrProcessor.h (right):

https://codereview.chromium.org/1734163002/diff/1/include/gpu/GrProcessor.h#n...
include/gpu/GrProcessor.h:125: void enableBuiltInState(BuiltInState state) {
fBuiltInState |= state; }
On 2016/02/25 21:11:03, bsalomon wrote:
> On 2016/02/25 20:38:37, Chris Dalton wrote:
> > On 2016/02/25 19:45:30, Chris Dalton wrote:
> > > On 2016/02/25 19:21:29, joshualitt wrote:
> > > > This is more a question for Brian / Robert, but do we want to hide the
> fact
> > > that
> > > > the implementation is a bit field? I kind of like
> > setWillReadFragmentPosition
> > > /
> > > > willReadFragmentPosition, though I also like that compose shader can
just
> > grab
> > > > the whole bitfield of its children.  Maybe retain the old
> > willRead/setWillRead
> > > > calls, but also allow access to the BuiltInState enum?  I don't really
> have
> > a
> > > > strong preference.
> > > 
> > > So, willRead isn't very needed anymore on this class. GrPipeline in this
> > change
> > > still keeps "willReadFragPosition", and that's where everybody else asks
> this
> > > question AFAIK.
> > 
> > Also, FWIW, this feels pretty similar to
> "fsBuilder->enableFeature(kMy_Feature)"
> 
> I find the setWillFoo() a bit more readable than enableFeature(kFoo). It
doesn't
> feel like these are inherently related, just happen to be sharing a bitfield
for
> implementation.
> 
> WRT children FPs, I really hope we replace the current mess of pulling state
> into the parent with a system that iterates over the DAG externally.

Ok, brought back "setWillFoo()".

For children FPs, I added a combineBuiltInState() method. We can gladly remove
it once child FPs change.

https://codereview.chromium.org/1734163002/diff/1/src/gpu/GrPipeline.cpp
File src/gpu/GrPipeline.cpp (right):

https://codereview.chromium.org/1734163002/diff/1/src/gpu/GrPipeline.cpp#newc...
src/gpu/GrPipeline.cpp:187: fBuiltInState = GrProcessor::kNone_BuiltInState;
On 2016/02/25 21:00:50, joshualitt wrote:
> On 2016/02/25 20:57:46, Chris Dalton wrote:
> > On 2016/02/25 20:50:27, joshualitt wrote:
> > > On 2016/02/25 20:38:37, Chris Dalton wrote:
> > > > We a problem here that fBuiltInState *should* intitialize with:
> > > > 
> > > >  fBuiltInState = GrPrimitiveProcessor.builtInState();
> > > > 
> > > > But I don't think the primitive processor is known yet at this point.
> > > Thoughts?
> > > > Otherwise if the primitive processor enables built in state, the
pipeline
> > > won't
> > > > know about it.
> > > > 
> > > 
> > > That should be okay.  We never remove the primitive processor, and it will
> > > always get a chance to modify the key / insert whatever code it wants. 
> > 
> > But the primitive processor might not exist yet, right?
> 
> right, but that should be okay because when we go to flush the draw we'll have
a
> GrPrimitiveProcessor + GrPipeline combination and at that point the
> GrPrimitiveProcessor can do whatever it wants, regardless of the builtinstate
> values on the GrPipeline.

I removed info about the fragment position from this class and from GrPocOptInfo
as we decided offline. (It didn't really belong in this class or GrProcOptInfo
anyway.)

[Chris Dalton, 2016-02-25 22:25:07]

Description was changed from

==========
Replace "willReadFragmentPosition" with a bitfield

Replaces uses of "willReadFragmentPosition" with a "BuiltInState"
bitfield. This will allow us to add additional built-in state.

BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

to

==========
Replace fWillReadFragmentPosition with a bitfield

Replaces fWillReadFragmentPosition on GrProcessor with a "BuiltInState"
bitfield. This will allow us to add additional built-in state.
Completely removes information about reading the fragment position from
GrPipeline and GrProcOptInfo.

BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

[joshualitt, 2016-02-26 13:02:50]

On 2016/02/25 22:24:24, Chris Dalton wrote:
> Ok, I think patchset 2 addresses most the concerns that came up.
> 
> https://codereview.chromium.org/1734163002/diff/1/include/gpu/GrProcessor.h
> File include/gpu/GrProcessor.h (right):
> 
>
https://codereview.chromium.org/1734163002/diff/1/include/gpu/GrProcessor.h#n...
> include/gpu/GrProcessor.h:125: void enableBuiltInState(BuiltInState state) {
> fBuiltInState |= state; }
> On 2016/02/25 21:11:03, bsalomon wrote:
> > On 2016/02/25 20:38:37, Chris Dalton wrote:
> > > On 2016/02/25 19:45:30, Chris Dalton wrote:
> > > > On 2016/02/25 19:21:29, joshualitt wrote:
> > > > > This is more a question for Brian / Robert, but do we want to hide the
> > fact
> > > > that
> > > > > the implementation is a bit field? I kind of like
> > > setWillReadFragmentPosition
> > > > /
> > > > > willReadFragmentPosition, though I also like that compose shader can
> just
> > > grab
> > > > > the whole bitfield of its children.  Maybe retain the old
> > > willRead/setWillRead
> > > > > calls, but also allow access to the BuiltInState enum?  I don't really
> > have
> > > a
> > > > > strong preference.
> > > > 
> > > > So, willRead isn't very needed anymore on this class. GrPipeline in this
> > > change
> > > > still keeps "willReadFragPosition", and that's where everybody else asks
> > this
> > > > question AFAIK.
> > > 
> > > Also, FWIW, this feels pretty similar to
> > "fsBuilder->enableFeature(kMy_Feature)"
> > 
> > I find the setWillFoo() a bit more readable than enableFeature(kFoo). It
> doesn't
> > feel like these are inherently related, just happen to be sharing a bitfield
> for
> > implementation.
> > 
> > WRT children FPs, I really hope we replace the current mess of pulling state
> > into the parent with a system that iterates over the DAG externally.
> 
> Ok, brought back "setWillFoo()".
> 
> For children FPs, I added a combineBuiltInState() method. We can gladly remove
> it once child FPs change.
> 
> https://codereview.chromium.org/1734163002/diff/1/src/gpu/GrPipeline.cpp
> File src/gpu/GrPipeline.cpp (right):
> 
>
https://codereview.chromium.org/1734163002/diff/1/src/gpu/GrPipeline.cpp#newc...
> src/gpu/GrPipeline.cpp:187: fBuiltInState = GrProcessor::kNone_BuiltInState;
> On 2016/02/25 21:00:50, joshualitt wrote:
> > On 2016/02/25 20:57:46, Chris Dalton wrote:
> > > On 2016/02/25 20:50:27, joshualitt wrote:
> > > > On 2016/02/25 20:38:37, Chris Dalton wrote:
> > > > > We a problem here that fBuiltInState *should* intitialize with:
> > > > > 
> > > > >  fBuiltInState = GrPrimitiveProcessor.builtInState();
> > > > > 
> > > > > But I don't think the primitive processor is known yet at this point.
> > > > Thoughts?
> > > > > Otherwise if the primitive processor enables built in state, the
> pipeline
> > > > won't
> > > > > know about it.
> > > > > 
> > > > 
> > > > That should be okay.  We never remove the primitive processor, and it
will
> > > > always get a chance to modify the key / insert whatever code it wants. 
> > > 
> > > But the primitive processor might not exist yet, right?
> > 
> > right, but that should be okay because when we go to flush the draw we'll
have
> a
> > GrPrimitiveProcessor + GrPipeline combination and at that point the
> > GrPrimitiveProcessor can do whatever it wants, regardless of the
builtinstate
> > values on the GrPipeline.
> 
> I removed info about the fragment position from this class and from
GrPocOptInfo
> as we decided offline. (It didn't really belong in this class or GrProcOptInfo
> anyway.)

lgtm

[Chris Dalton, 2016-02-26 16:22:07]

The CQ bit was checked by cdalton@nvidia.com

[commit-bot: I haz the power, 2016-02-26 16:22:20]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1734163002/40001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1734163002/40001

[commit-bot: I haz the power, 2016-02-26 16:23:38]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-02-26 16:23:39]

Try jobs failed on following builders:
  skia_presubmit-Trybot on client.skia.fyi (JOB_FAILED,
http://build.chromium.org/p/client.skia.fyi/builders/skia_presubmit-Trybot/bu...)

[Chris Dalton, 2016-02-26 16:25:24]

On 2016/02/26 16:23:39, commit-bot: I haz the power wrote:
> Try jobs failed on following builders:
>   skia_presubmit-Trybot on client.skia.fyi (JOB_FAILED,
>
http://build.chromium.org/p/client.skia.fyi/builders/skia_presubmit-Trybot/bu...)

Oops, forgot this change touched a file in the public API.

[bsalomon, 2016-02-26 16:58:32]

lgtm, but not crazy about the name BuiltInState.

We usually use the term "Flags" for bitfield enums.

FeatureUseFlags? RequiredFragmentVarFlags? ...

Also, if you like you could use enum class, e.g.:

enum class RequiredFragmentVarFlags : uint32_t {
   kNone               = 0x0,
   kFragmentPosition   = 0x1,
   kSampleMask         = 0x2,
}

[Chris Dalton, 2016-02-26 19:50:29]

Description was changed from

==========
Replace fWillReadFragmentPosition with a bitfield

Replaces fWillReadFragmentPosition on GrProcessor with a "BuiltInState"
bitfield. This will allow us to add additional built-in state.
Completely removes information about reading the fragment position from
GrPipeline and GrProcOptInfo.

BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

to

==========
Replace fWillReadFragmentPosition with a bitfield

Replaces fWillReadFragmentPosition on GrProcessor with a 
"RequiredFeatures" bitfield. This will allow us to add additional 
built-in features. Completely removes information about reading the
fragment position from GrPipeline and GrProcOptInfo.


BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

[Chris Dalton, 2016-02-26 19:51:47]

On 2016/02/26 16:58:32, bsalomon wrote:
> lgtm, but not crazy about the name BuiltInState.
> 
> We usually use the term "Flags" for bitfield enums.
> 
> FeatureUseFlags? RequiredFragmentVarFlags? ...
> 
> Also, if you like you could use enum class, e.g.:
> 
> enum class RequiredFragmentVarFlags : uint32_t {
>    kNone               = 0x0,
>    kFragmentPosition   = 0x1,
>    kSampleMask         = 0x2,
> }

As discussed offline, renamed to RequiredFeatures and did not use enum class due
to issues converting to bool.

[bsalomon, 2016-02-26 19:54:15]

lgtm

[Chris Dalton, 2016-02-26 19:55:38]

The CQ bit was checked by cdalton@nvidia.com

[Chris Dalton, 2016-02-26 19:55:38]

The patchset sent to the CQ was uploaded after l-g-t-m from
joshualitt@google.com
Link to the patchset: https://codereview.chromium.org/1734163002/#ps60001
(title: "BuiltInState -> RequiredFeatures")

[commit-bot: I haz the power, 2016-02-26 19:55:45]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1734163002/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1734163002/60001

[commit-bot: I haz the power, 2016-02-26 20:22:05]

Description was changed from

==========
Replace fWillReadFragmentPosition with a bitfield

Replaces fWillReadFragmentPosition on GrProcessor with a 
"RequiredFeatures" bitfield. This will allow us to add additional 
built-in features. Completely removes information about reading the
fragment position from GrPipeline and GrProcOptInfo.


BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

to

==========
Replace fWillReadFragmentPosition with a bitfield

Replaces fWillReadFragmentPosition on GrProcessor with a 
"RequiredFeatures" bitfield. This will allow us to add additional 
built-in features. Completely removes information about reading the
fragment position from GrPipeline and GrProcOptInfo.


BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...

Committed:
https://skia.googlesource.com/skia/+/87332103c605dc3e0f76c0d1250a76c4ff71fddc
==========

[commit-bot: I haz the power, 2016-02-26 20:22:06]

Committed patchset #4 (id:60001) as
https://skia.googlesource.com/skia/+/87332103c605dc3e0f76c0d1250a76c4ff71fddc