API change to allow for NormalSource selection at the user level.

API change to allow for NormalSource selection at the user level.

This CL's base is the CL for CPU handling: https://codereview.chromium.org/2050773002/

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2063793002

Committed: https://skia.googlesource.com/skia/+/5b794fad18344e8dbb840be49d1bc66ebe754b31

[dvonbeck, 2016-06-13 17:03:13]

Description was changed from

==========
API change to allow for NormalSource selection at the user level.

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

to

==========
API change to allow for NormalSource selection at the user level.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2063793002
==========

[dvonbeck, 2016-06-13 17:08:06]

Description was changed from

==========
API change to allow for NormalSource selection at the user level.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2063793002
==========

to

==========
API change to allow for NormalSource selection at the user level.

This CL's base is the CL for CPU handling:
https://codereview.chromium.org/2050773002/

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2063793002
==========

[dvonbeck, 2016-06-14 17:34:43]

dvonbeck@google.com changed reviewers:
+ egdaniel@google.com

[egdaniel, 2016-06-16 13:15:08]

https://codereview.chromium.org/2063793002/diff/20001/gm/lightingshader.cpp
File gm/lightingshader.cpp (right):

https://codereview.chromium.org/2063793002/diff/20001/gm/lightingshader.cpp#n...
gm/lightingshader.cpp:104: paint.setShader(SkLightingShader::Make(fDiffuse,
fLights, &matrix, normalSource));
should this be a move here of normal source?

https://codereview.chromium.org/2063793002/diff/20001/samplecode/SampleLighti...
File samplecode/SampleLighting.cpp (right):

https://codereview.chromium.org/2063793002/diff/20001/samplecode/SampleLighti...
samplecode/SampleLighting.cpp:71: normalSource));
move?

https://codereview.chromium.org/2063793002/diff/20001/src/core/SkLightingShad...
File src/core/SkLightingShader.cpp (right):

https://codereview.chromium.org/2063793002/diff/20001/src/core/SkLightingShad...
src/core/SkLightingShader.cpp:575: const SkMatrix* diffLocalM,
sk_sp<NormalSource> normalSource) {
We should either check or at minimum assert that normalSource is not null here

https://codereview.chromium.org/2063793002/diff/20001/src/core/SkLightingShad...
File src/core/SkLightingShader.h (right):

https://codereview.chromium.org/2063793002/diff/20001/src/core/SkLightingShad...
src/core/SkLightingShader.h:37: 
extra spaces added here?

[dvonbeck, 2016-06-16 23:21:57]

https://codereview.chromium.org/2063793002/diff/20001/gm/lightingshader.cpp
File gm/lightingshader.cpp (right):

https://codereview.chromium.org/2063793002/diff/20001/gm/lightingshader.cpp#n...
gm/lightingshader.cpp:104: paint.setShader(SkLightingShader::Make(fDiffuse,
fLights, &matrix, normalSource));
On 2016/06/16 13:15:08, egdaniel wrote:
> should this be a move here of normal source?

Done.

https://codereview.chromium.org/2063793002/diff/20001/samplecode/SampleLighti...
File samplecode/SampleLighting.cpp (right):

https://codereview.chromium.org/2063793002/diff/20001/samplecode/SampleLighti...
samplecode/SampleLighting.cpp:71: normalSource));
On 2016/06/16 13:15:08, egdaniel wrote:
> move?

Done.

https://codereview.chromium.org/2063793002/diff/20001/src/core/SkLightingShad...
File src/core/SkLightingShader.cpp (right):

https://codereview.chromium.org/2063793002/diff/20001/src/core/SkLightingShad...
src/core/SkLightingShader.cpp:575: const SkMatrix* diffLocalM,
sk_sp<NormalSource> normalSource) {
On 2016/06/16 13:15:08, egdaniel wrote:
> We should either check or at minimum assert that normalSource is not null here

Done. Will return a default implementation of NormalSource on a later CL.

https://codereview.chromium.org/2063793002/diff/20001/src/core/SkLightingShad...
File src/core/SkLightingShader.h (right):

https://codereview.chromium.org/2063793002/diff/20001/src/core/SkLightingShad...
src/core/SkLightingShader.h:37: 
On 2016/06/16 13:15:08, egdaniel wrote:
> extra spaces added here?

Oops, that was an accident. Reverted. Are space-only lines like that one
something I should not do?

[egdaniel, 2016-06-21 14:28:07]

lgtm once we get cpu change CL in

[dvonbeck, 2016-06-24 17:10:19]

rebase

[dvonbeck, 2016-06-27 19:07:46]

API now takes in CTM for normal rotation. Probably needs re-review.

[dvonbeck, 2016-06-27 22:25:06]

Description was changed from

==========
API change to allow for NormalSource selection at the user level.

This CL's base is the CL for CPU handling:
https://codereview.chromium.org/2050773002/

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2063793002
==========

to

==========
API change to allow for NormalSource selection at the user level.

DO NOT LAND. MATH IS WRONG. 

This CL's base is the CL for CPU handling:
https://codereview.chromium.org/2050773002/

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2063793002
==========

[dvonbeck, 2016-06-28 14:50:27]

Description was changed from

==========
API change to allow for NormalSource selection at the user level.

DO NOT LAND. MATH IS WRONG. 

This CL's base is the CL for CPU handling:
https://codereview.chromium.org/2050773002/

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2063793002
==========

to

==========
API change to allow for NormalSource selection at the user level.

This CL's base is the CL for CPU handling:
https://codereview.chromium.org/2050773002/

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2063793002
==========

[robertphillips, 2016-07-06 15:30:45]

robertphillips@google.com changed reviewers:
+ robertphillips@google.com

[robertphillips, 2016-07-06 15:30:45]

ping

[robertphillips, 2016-07-06 16:36:34]

https://codereview.chromium.org/2063793002/diff/140001/gm/lightingshader.cpp
File gm/lightingshader.cpp (right):

https://codereview.chromium.org/2063793002/diff/140001/gm/lightingshader.cpp#...
gm/lightingshader.cpp:53: builder.add(SkLights::Light(SkColor3f::Make(1.0f,
1.0f, 1.0f),
I think you want this to be normalized: 
 (SK_ScalarRoot2Over2, 0.0f, SK_ScalarRoot2Over2)
?

https://codereview.chromium.org/2063793002/diff/140001/samplecode/SampleLight...
File samplecode/SampleLighting.cpp (right):

https://codereview.chromium.org/2063793002/diff/140001/samplecode/SampleLight...
samplecode/SampleLighting.cpp:71: sk_sp<SkNormalSource> normalSource =
SkNormalSource::MakeFromNormalMap(
Why can't you use SkMatrix::I() ?

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkLightingSha...
File src/core/SkLightingShader.cpp (right):

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkLightingSha...
src/core/SkLightingShader.cpp:59: 
Can we not do this in the ctor list with the others ?

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkLightingSha...
src/core/SkLightingShader.cpp:305: // we assume diffuse and normal maps have
same width and height
Do we test different sized diffuse maps & light maps ?
If not, we should but in a different CL.

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkLightingSha...
src/core/SkLightingShader.cpp:572: sk_sp<SkShader> SkLightingShader::Make(const
SkBitmap& diffuse, sk_sp<SkLights> lights,
tab the following line over to match up with the '('

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkLightingSha...
File src/core/SkLightingShader.h (right):

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkLightingSha...
src/core/SkLightingShader.h:19: public:
"map and normals with" -> "map using the normals and" ?

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
File src/core/SkNormalSource.cpp (right):

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:100: const char* xformUniName = nullptr;
It looks like we only use the upper left 2x2 - why upload the entire thing ?

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:111: 
A branch in the shader is expensive !

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:113: fragBuilder->codeAppend( "if (abs(normal.z) >
0.9999) {");
Might as well just set it to (0, 0, 1, 0).

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:124: fragBuilder->codeAppend( "    float
scalingFactorSquared = "
Using pows for squares seems a bit overkill.

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:252: 
There 3 overlength lines here.

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:269: } else {
Might as well just set this to (0, 0, 1) and skip the normalization.

[dvonbeck, 2016-07-06 18:07:49]

https://codereview.chromium.org/2063793002/diff/140001/gm/lightingshader.cpp
File gm/lightingshader.cpp (right):

https://codereview.chromium.org/2063793002/diff/140001/gm/lightingshader.cpp#...
gm/lightingshader.cpp:53: builder.add(SkLights::Light(SkColor3f::Make(1.0f,
1.0f, 1.0f),
On 2016/07/06 16:36:33, robertphillips wrote:
> I think you want this to be normalized: 
>  (SK_ScalarRoot2Over2, 0.0f, SK_ScalarRoot2Over2)
> ?

It gets normalized by the constructor, should I still change it?

https://codereview.chromium.org/2063793002/diff/140001/samplecode/SampleLight...
File samplecode/SampleLighting.cpp (right):

https://codereview.chromium.org/2063793002/diff/140001/samplecode/SampleLight...
samplecode/SampleLighting.cpp:71: sk_sp<SkNormalSource> normalSource =
SkNormalSource::MakeFromNormalMap(
On 2016/07/06 16:36:33, robertphillips wrote:
> Why can't you use SkMatrix::I() ?

Oops. Done. Should have known!

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkLightingSha...
File src/core/SkLightingShader.cpp (right):

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkLightingSha...
src/core/SkLightingShader.cpp:59: 
On 2016/07/06 16:36:33, robertphillips wrote:
> Can we not do this in the ctor list with the others ?

Done. I seem to have realized it in a future CL and changed it there, but got
left as-is here by accident.

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkLightingSha...
src/core/SkLightingShader.cpp:305: // we assume diffuse and normal maps have
same width and height
On 2016/07/06 16:36:33, robertphillips wrote:
> Do we test different sized diffuse maps & light maps ?
> If not, we should but in a different CL.

This assumption disappears once both normals and diffuse colors are sourced from
arbitrary shaders. I agree, we should add a GM or something.

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkLightingSha...
src/core/SkLightingShader.cpp:572: sk_sp<SkShader> SkLightingShader::Make(const
SkBitmap& diffuse, sk_sp<SkLights> lights,
On 2016/07/06 16:36:33, robertphillips wrote:
> tab the following line over to match up with the '('

If I do, then the line is over 100 columns. Is this still not according to the
preferred style? What's the preferred style here? Should I have each argument in
its own line?

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkLightingSha...
File src/core/SkLightingShader.h (right):

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkLightingSha...
src/core/SkLightingShader.h:19: public:
On 2016/07/06 16:36:33, robertphillips wrote:
> "map and normals with" -> "map using the normals and" ?

Done.

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
File src/core/SkNormalSource.cpp (right):

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:100: const char* xformUniName = nullptr;
On 2016/07/06 16:36:33, robertphillips wrote:
> It looks like we only use the upper left 2x2 - why upload the entire thing ?

Done.

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:111: 
On 2016/07/06 16:36:34, robertphillips wrote:
> A branch in the shader is expensive !

The code seemed to run just fine ignoring the division by 0 problem, at least on
my computer, even when the normals were all (0, 0, 1). Should I get rid of the
branching, and then see when triaging if it causes problems in other types of
hardware?

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:113: fragBuilder->codeAppend( "if (abs(normal.z) >
0.9999) {");
On 2016/07/06 16:36:33, robertphillips wrote:
> Might as well just set it to (0, 0, 1, 0).

Needs to handle (0, 0, -1, 0) as well. I could set it to normalize(normal) if
that makes more sense.

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:124: fragBuilder->codeAppend( "    float
scalingFactorSquared = "
On 2016/07/06 16:36:34, robertphillips wrote:
> Using pows for squares seems a bit overkill.

Should I be using *?

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:252: 
On 2016/07/06 16:36:33, robertphillips wrote:
> There 3 overlength lines here.

Done.

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:269: } else {
On 2016/07/06 16:36:34, robertphillips wrote:
> Might as well just set this to (0, 0, 1) and skip the normalization.

Needs to handle (0, 0, -1) as well. I could set it to tempNorm if that makes
more sense.

[robertphillips, 2016-07-06 19:11:14]

https://codereview.chromium.org/2063793002/diff/140001/gm/lightingshader.cpp
File gm/lightingshader.cpp (right):

https://codereview.chromium.org/2063793002/diff/140001/gm/lightingshader.cpp#...
gm/lightingshader.cpp:53: builder.add(SkLights::Light(SkColor3f::Make(1.0f,
1.0f, 1.0f),
On 2016/07/06 18:07:48, dvonbeck wrote:
> On 2016/07/06 16:36:33, robertphillips wrote:
> > I think you want this to be normalized: 
> >  (SK_ScalarRoot2Over2, 0.0f, SK_ScalarRoot2Over2)
> > ?
> 
> It gets normalized by the constructor, should I still change it?

It will probably make more sense to the reader. Otherwise they have to normalize
it in their heads to figure out where to expect the light.

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkLightingSha...
File src/core/SkLightingShader.cpp (right):

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkLightingSha...
src/core/SkLightingShader.cpp:305: // we assume diffuse and normal maps have
same width and height
On 2016/07/06 18:07:48, dvonbeck wrote:
> On 2016/07/06 16:36:33, robertphillips wrote:
> > Do we test different sized diffuse maps & light maps ?
> > If not, we should but in a different CL.
> 
> This assumption disappears once both normals and diffuse colors are sourced
from
> arbitrary shaders. I agree, we should add a GM or something.

Do you have a task list (or something) to add it to?

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkLightingSha...
src/core/SkLightingShader.cpp:572: sk_sp<SkShader> SkLightingShader::Make(const
SkBitmap& diffuse, sk_sp<SkLights> lights,
On 2016/07/06 18:07:48, dvonbeck wrote:
> On 2016/07/06 16:36:33, robertphillips wrote:
> > tab the following line over to match up with the '('
> 
> If I do, then the line is over 100 columns. Is this still not according to the
> preferred style? What's the preferred style here? Should I have each argument
in
> its own line?

Right, tab it over and add newlines as necessary.

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
File src/core/SkNormalSource.cpp (right):

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:111: 
On 2016/07/06 18:07:48, dvonbeck wrote:
> On 2016/07/06 16:36:34, robertphillips wrote:
> > A branch in the shader is expensive !
> 
> The code seemed to run just fine ignoring the division by 0 problem, at least
on
> my computer, even when the normals were all (0, 0, 1). Should I get rid of the
> branching, and then see when triaging if it causes problems in other types of
> hardware?

I would say leave the guard for now. I just wanted you to be aware of the perf
cost.

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:113: fragBuilder->codeAppend( "if (abs(normal.z) >
0.9999) {");
On 2016/07/06 18:07:48, dvonbeck wrote:
> On 2016/07/06 16:36:33, robertphillips wrote:
> > Might as well just set it to (0, 0, 1, 0).
> 
> Needs to handle (0, 0, -1, 0) as well. I could set it to normalize(normal) if
> that makes more sense.

Okay - leave it as is.

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:124: fragBuilder->codeAppend( "    float
scalingFactorSquared = "
On 2016/07/06 18:07:48, dvonbeck wrote:
> On 2016/07/06 16:36:34, robertphillips wrote:
> > Using pows for squares seems a bit overkill.
> 
> Should I be using *?

Right, I would just have multiplies. The compiler should convert the pow(*, 2)
calls to multiplies for you but, who knows.

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:269: } else {
On 2016/07/06 18:07:48, dvonbeck wrote:
> On 2016/07/06 16:36:34, robertphillips wrote:
> > Might as well just set this to (0, 0, 1) and skip the normalization.
> 
> Needs to handle (0, 0, -1) as well. I could set it to tempNorm if that makes
> more sense.

Nope, just leave it as is.

[dvonbeck, 2016-07-06 19:34:36]

https://codereview.chromium.org/2063793002/diff/140001/gm/lightingshader.cpp
File gm/lightingshader.cpp (right):

https://codereview.chromium.org/2063793002/diff/140001/gm/lightingshader.cpp#...
gm/lightingshader.cpp:53: builder.add(SkLights::Light(SkColor3f::Make(1.0f,
1.0f, 1.0f),
On 2016/07/06 19:11:13, robertphillips wrote:
> On 2016/07/06 18:07:48, dvonbeck wrote:
> > On 2016/07/06 16:36:33, robertphillips wrote:
> > > I think you want this to be normalized: 
> > >  (SK_ScalarRoot2Over2, 0.0f, SK_ScalarRoot2Over2)
> > > ?
> > 
> > It gets normalized by the constructor, should I still change it?
> 
> It will probably make more sense to the reader. Otherwise they have to
normalize
> it in their heads to figure out where to expect the light.

Done.

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkLightingSha...
File src/core/SkLightingShader.cpp (right):

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkLightingSha...
src/core/SkLightingShader.cpp:305: // we assume diffuse and normal maps have
same width and height
On 2016/07/06 19:11:14, robertphillips wrote:
> On 2016/07/06 18:07:48, dvonbeck wrote:
> > On 2016/07/06 16:36:33, robertphillips wrote:
> > > Do we test different sized diffuse maps & light maps ?
> > > If not, we should but in a different CL.
> > 
> > This assumption disappears once both normals and diffuse colors are sourced
> from
> > arbitrary shaders. I agree, we should add a GM or something.
> 
> Do you have a task list (or something) to add it to?

Yes, I added it

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkLightingSha...
src/core/SkLightingShader.cpp:572: sk_sp<SkShader> SkLightingShader::Make(const
SkBitmap& diffuse, sk_sp<SkLights> lights,
On 2016/07/06 19:11:14, robertphillips wrote:
> On 2016/07/06 18:07:48, dvonbeck wrote:
> > On 2016/07/06 16:36:33, robertphillips wrote:
> > > tab the following line over to match up with the '('
> > 
> > If I do, then the line is over 100 columns. Is this still not according to
the
> > preferred style? What's the preferred style here? Should I have each
argument
> in
> > its own line?
> 
> Right, tab it over and add newlines as necessary.

Done.

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
File src/core/SkNormalSource.cpp (right):

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:111: 
On 2016/07/06 19:11:14, robertphillips wrote:
> On 2016/07/06 18:07:48, dvonbeck wrote:
> > On 2016/07/06 16:36:34, robertphillips wrote:
> > > A branch in the shader is expensive !
> > 
> > The code seemed to run just fine ignoring the division by 0 problem, at
least
> on
> > my computer, even when the normals were all (0, 0, 1). Should I get rid of
the
> > branching, and then see when triaging if it causes problems in other types
of
> > hardware?
> 
> I would say leave the guard for now. I just wanted you to be aware of the perf
> cost.

Alright! I think it should be fine here considering the size of the code blocks.

https://codereview.chromium.org/2063793002/diff/140001/src/core/SkNormalSourc...
src/core/SkNormalSource.cpp:124: fragBuilder->codeAppend( "    float
scalingFactorSquared = "
On 2016/07/06 19:11:14, robertphillips wrote:
> On 2016/07/06 18:07:48, dvonbeck wrote:
> > On 2016/07/06 16:36:34, robertphillips wrote:
> > > Using pows for squares seems a bit overkill.
> > 
> > Should I be using *?
> 
> Right, I would just have multiplies. The compiler should convert the pow(*, 2)
> calls to multiplies for you but, who knows.

Done.

[robertphillips, 2016-07-06 20:28:47]

lgtm

[robertphillips, 2016-07-06 20:28:55]

The CQ bit was checked by robertphillips@google.com to run a CQ dry run

[commit-bot: I haz the power, 2016-07-06 20:28:59]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-06 20:53:42]

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

[commit-bot: I haz the power, 2016-07-06 20:53:43]

Dry run: This issue passed the CQ dry run.

[dvonbeck, 2016-07-06 20:57:27]

The CQ bit was checked by dvonbeck@google.com

[dvonbeck, 2016-07-06 20:57:28]

The patchset sent to the CQ was uploaded after l-g-t-m from egdaniel@google.com
Link to the patchset: https://codereview.chromium.org/2063793002/#ps200001
(title: "Addressed remaining patch 8 comments")

[commit-bot: I haz the power, 2016-07-06 20:57:31]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-06 20:58:39]

Description was changed from

==========
API change to allow for NormalSource selection at the user level.

This CL's base is the CL for CPU handling:
https://codereview.chromium.org/2050773002/

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2063793002
==========

to

==========
API change to allow for NormalSource selection at the user level.

This CL's base is the CL for CPU handling:
https://codereview.chromium.org/2050773002/

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2063793002

Committed:
https://skia.googlesource.com/skia/+/5b794fad18344e8dbb840be49d1bc66ebe754b31
==========

[commit-bot: I haz the power, 2016-07-06 20:58:40]

Committed patchset #11 (id:200001) as
https://skia.googlesource.com/skia/+/5b794fad18344e8dbb840be49d1bc66ebe754b31