Implement color filter as GrGLEffect

Implement SkColorFilter as a GrGLEffect

Adds GrEffect::willUseInputColor() which indicates whether or not the
input color affects the output of the effect. This is needed for
certain Xfermodes, such as kSrc_Mode. For these modes the color filter
will not use the input color.

An effect with GrEffect::willUseInputColor() true will cause all color
or coverage effects before it to be discarded, as their computations
cannot affect the output. In these cases program is marked as having
white input color.

This fixes an assert when Skia is compiled in a mode that prefers
using uniforms instead of attributes for constants. (Flags
GR_GL_USE_NV_PATH_RENDERING or GR_GL_NO_CONSTANT_ATTRIBUTES). Using
attributes hides the problem where the fragment shader does not need
input color for color filters that ignore DST part of the filter. The
assert would be hit when uniform manager tries to bind an uniform which
has been optimized away by the shader compiler.

Adds specific GrGLSLExpr4 and GrGLSLExpr1 classes. This way the GLSL
expressions like "(v - src.a)" can remain somewhat readable in form of
"(v - src.a())". The GrGLSLExpr<typename> template implements the
generic functionality, GrGLSLExprX is the specialization that exposes
the type-safe interface to this functionality.

Also adds operators so that GLSL binary operators of the form
"(float * vecX)" can be expressed in C++. Before only the equivalent
"(vecX * float)" was possible. This reverts the common blending
calculations to more conventional order, such as "(1-a) * c" instead of
"c * (1-a)".

Changes GrGLSLExpr1::OnesStr from 1 to 1.0 in order to preserve the
color filter blending formula string the same (with the exception of
variable name change).

Shaders change in case of input color being needed:
 -   vec4 filteredColor;
 -   filteredColor = (((1.0 - uFilterColor.a) * output_Stage0) + uFilterColor);
 -   fsColorOut = filteredColor;
 +   vec4 output_Stage1;
 +   { // Stage 1: ModeColorFilterEffect
 +   output_Stage1 = (((1.0 - uFilterColor_Stage1.a) * output_Stage0) + uFilterColor_Stage1);
 +   }
 +   fsColorOut = output_Stage1;

Shaders change in case of input color being not needed:
 -uniform vec4 uFilterColor;
 -in vec4 vColor;
 +uniform vec4 uFilterColor_Stage0;
  out vec4 fsColorOut;
  void main() {
 -   vec4 filteredColor;
 -   filteredColor = uFilterColor;
 -   fsColorOut = filteredColor;
 +   vec4 output_Stage0;
 +   { // Stage 0: ModeColorFilterEffect
 +   output_Stage0 = uFilterColor_Stage0;
 +   }
 +   fsColorOut = output_Stage0;
  }

Committed: http://code.google.com/p/skia/source/detail?r=11912

[Kimmo Kinnunen, 2013-09-27 13:39:10]

depends on https://codereview.chromium.org/25048002

[Kimmo Kinnunen, 2013-09-27 13:41:12]

Brian, ran into this while implementing NVPR. This is a work in progress.. Do
you think it makes sense for me to work on this further or is there somebody
fixing this in a better way?

[bsalomon, 2013-09-27 13:59:38]

Kimmo, Thanks for this!

I think we may want to change GrEffect::getConstantColorComponents() into
something that incorporates your willUseInputColor(). I'm thinking something
like this:

enum OptFlags {
   kIgnoresInput_OptFlag = 0x1,
};

/** ... returns a bitfield of OptFlags ...  */
uint32_t getOptimizations(GrColor* constantColor, uint32_t* constantColorComps)
const;


I'd like to eventually merge the implementation of the new effect in
SkXfermode.cpp but that can be a battle for another day. We also would like to
move away from the Mode enum in the long term.

https://codereview.chromium.org/25023003/diff/1/src/gpu/gl/GrGLProgram.cpp
File src/gpu/gl/GrGLProgram.cpp (right):

https://codereview.chromium.org/25023003/diff/1/src/gpu/gl/GrGLProgram.cpp#ne...
src/gpu/gl/GrGLProgram.cpp:403: if (!inColor.isValid()) {
What's this about?

[Kimmo Kinnunen, 2013-10-01 12:44:36]

On 2013/09/27 13:59:38, bsalomon wrote:
> Kimmo, Thanks for this!
> 
> I think we may want to change GrEffect::getConstantColorComponents() into
> something that incorporates your willUseInputColor(). I'm thinking something
> like this:
> 
> enum OptFlags {
>    kIgnoresInput_OptFlag = 0x1,
> };
> 
> /** ... returns a bitfield of OptFlags ...  */
> uint32_t getOptimizations(GrColor* constantColor, uint32_t*
constantColorComps)
> const;

I'm not sure it makes sense? If you look at getConstantColorComponents() and
willUseInputColor() call sites: information the calls convey do not really
interact, they're used in different parts of the system.

If the two would be merged, willUseInputColor would be always "result =
getOptimizations(NULL, NULL)" and getConstantColorComponents would always be
"(void) getOptimizations(&a, &b)".  They'd be always used as different
functions, even though the functions would just be implemented inside the same
c++ function.
"API" wise it'd be suboptimal too, as the always-discarded return value would be
always calculated.

If you have time, please take a look at the new patch. This should be ready for
review. If you think the bitfield is the way to go, we can of course come back
to the subject.


>
https://codereview.chromium.org/25023003/diff/1/src/gpu/gl/GrGLProgram.cpp#ne...
> src/gpu/gl/GrGLProgram.cpp:403: if (!inColor.isValid()) {
> What's this about?

Just a rebase leftover. Fixed.

[Kimmo Kinnunen, 2013-10-01 12:55:46]

https://codereview.chromium.org/25023003/diff/11001/src/effects/SkColorFilter...
File src/effects/SkColorFilters.cpp (right):

https://codereview.chromium.org/25023003/diff/11001/src/effects/SkColorFilter...
src/effects/SkColorFilters.cpp:366: void
ModeColorFilterEffect::getConstantColorComponents(GrColor* color, uint32_t*
validFlags) const {
Btw: It'd be great to be able to unit test these sort of things. There's the
problem of lack of .h file, so a new test .cpp file is not possible. Some sort
of static constructor -based test function discovery would be needed (similar to
DEFINE_EFFECT_TEST) unless the interface would be exposed in .h.

Any opinion on should this method be tested directly? Any opinion on how to
setup and run the test?

[Kimmo Kinnunen, 2013-10-02 12:35:25]

Found the solution to the test question..

[bsalomon, 2013-10-02 15:32:53]

On 2013/10/01 12:44:36, kkinnunen wrote:
> On 2013/09/27 13:59:38, bsalomon wrote:
> > Kimmo, Thanks for this!
> > 
> > I think we may want to change GrEffect::getConstantColorComponents() into
> > something that incorporates your willUseInputColor(). I'm thinking something
> > like this:
> > 
> > enum OptFlags {
> >    kIgnoresInput_OptFlag = 0x1,
> > };
> > 
> > /** ... returns a bitfield of OptFlags ...  */
> > uint32_t getOptimizations(GrColor* constantColor, uint32_t*
> constantColorComps)
> > const;
> 
> I'm not sure it makes sense? If you look at getConstantColorComponents() and
> willUseInputColor() call sites: information the calls convey do not really
> interact, they're used in different parts of the system.
> 
> If the two would be merged, willUseInputColor would be always "result =
> getOptimizations(NULL, NULL)" and getConstantColorComponents would always be
> "(void) getOptimizations(&a, &b)".  They'd be always used as different
> functions, even though the functions would just be implemented inside the same
> c++ function.
> "API" wise it'd be suboptimal too, as the always-discarded return value would
be
> always calculated.
> 
> If you have time, please take a look at the new patch. This should be ready
for
> review. If you think the bitfield is the way to go, we can of course come back
> to the subject.
> 

I was thinking that when building GrGLProgramDesc we would loop on the effects
and want both pieces of information. We can omit any effects that produce a
constant color and any effects prior to the last effect that reports that it
ignores its predecessor's output.

But you're right that it does seems like there are several callers that only
want one or the other. So, it's probably best to keep them separate.

I'll have a look at the latest patchset.

[bsalomon, 2013-10-02 16:37:58]

https://codereview.chromium.org/25023003/diff/21001/src/effects/SkColorFilter...
File src/effects/SkColorFilters.cpp (right):

https://codereview.chromium.org/25023003/diff/21001/src/effects/SkColorFilter...
src/effects/SkColorFilters.cpp:304: * flags through the blending equation.
"It has members similar to GrGLSLExpr so that it can be used with the templated
helpers above."?

https://codereview.chromium.org/25023003/diff/21001/src/effects/SkColorFilter...
src/effects/SkColorFilters.cpp:308: MaskedColorExpr(const GrGLfloat color[],
uint32_t flags)
maybe just float or SkScalar? We usually only use GrGLfloat for things that are
passed to functions that take GLfloat.

https://codereview.chromium.org/25023003/diff/21001/src/gpu/GrDrawState.h
File src/gpu/GrDrawState.h (right):

https://codereview.chromium.org/25023003/diff/21001/src/gpu/GrDrawState.h#new...
src/gpu/GrDrawState.h:351: if (!(*effect)->willUseInputColor()) {
I don't think this is safe because of AutoRestoreEffects(). We either need to
address that, or just keep the effects around and ignore them when we turn this
draw state into a program (skip effects before an effect that ignores its
input).

Also, I think we would want similar logic in addCoverageEffect().

[Kimmo Kinnunen, 2013-10-04 06:21:18]

https://chromiumcodereview.appspot.com/25023003/diff/21001/src/effects/SkColo...
File src/effects/SkColorFilters.cpp (right):

https://chromiumcodereview.appspot.com/25023003/diff/21001/src/effects/SkColo...
src/effects/SkColorFilters.cpp:304: * flags through the blending equation.
On 2013/10/02 16:37:59, bsalomon wrote:
> "It has members similar to GrGLSLExpr so that it can be used with the
templated
> helpers above."?

Done.

https://chromiumcodereview.appspot.com/25023003/diff/21001/src/effects/SkColo...
src/effects/SkColorFilters.cpp:308: MaskedColorExpr(const GrGLfloat color[],
uint32_t flags)
On 2013/10/02 16:37:59, bsalomon wrote:
> maybe just float or SkScalar? We usually only use GrGLfloat for things that
are
> passed to functions that take GLfloat.

Done.

https://chromiumcodereview.appspot.com/25023003/diff/21001/src/gpu/GrDrawState.h
File src/gpu/GrDrawState.h (right):

https://chromiumcodereview.appspot.com/25023003/diff/21001/src/gpu/GrDrawStat...
src/gpu/GrDrawState.h:351: if (!(*effect)->willUseInputColor()) {
On 2013/10/02 16:37:59, bsalomon wrote:
> I don't think this is safe because of AutoRestoreEffects(). We either need to
> address that, or just keep the effects around and ignore them when we turn
this
> draw state into a program (skip effects before an effect that ignores its
> input).
> 
> Also, I think we would want similar logic in addCoverageEffect().

Done. Not sure the new naming is the best possible, though.

[bsalomon, 2013-10-07 14:04:59]

Kimmo, I just noticed that you have a number of issues with uploaded patches but
haven't posted msgs via "publish+mail comments". Unless you publish reviewers
don't get any notification and don't know whether your ready for another look.

https://codereview.chromium.org/25023003/diff/52001/src/gpu/GrDrawState.h
File src/gpu/GrDrawState.h (right):

https://codereview.chromium.org/25023003/diff/52001/src/gpu/GrDrawState.h#new...
src/gpu/GrDrawState.h:1063: class EffectStageArray {
It seems like we'd be adding a fair amount of complexity to keep the live effect
set minimal. Unless there is a downside, it seems like it'd be a lot simpler to
leave it as it was and just toss some of the effects when we go to build the
program descriptor. We have to walk them all anyway. Maybe I'm missing
something.

[Kimmo Kinnunen, 2013-10-10 08:12:28]

Thanks. How about the new version?

https://codereview.chromium.org/25023003/diff/52001/src/gpu/GrDrawState.h
File src/gpu/GrDrawState.h (right):

https://codereview.chromium.org/25023003/diff/52001/src/gpu/GrDrawState.h#new...
src/gpu/GrDrawState.h:1063: class EffectStageArray {
On 2013/10/07 14:05:00, bsalomon wrote:
> It seems like we'd be adding a fair amount of complexity to keep the live
effect
> set minimal. Unless there is a downside, it seems like it'd be a lot simpler
to
> leave it as it was and just toss some of the effects when we go to build the
> program descriptor. We have to walk them all anyway. Maybe I'm missing
> something.

Done.

[Kimmo Kinnunen, 2013-10-11 12:58:10]

Hmm. I think the client code using GrGLSLExpr becomes unclear.
Maybe I can still refine this a bit?

[Kimmo Kinnunen, 2013-10-14 14:17:15]

This is maybe a bit simpler.
Example of how it would expand: https://codereview.chromium.org/26190003/

[bsalomon, 2013-10-18 14:10:16]

Kimmo, sorry letting this fall off my radar! One small request: can
willUseInputColor be made more consistent with willReadDstColor and
willReadFragmentPosition? What I mean is that rather than a virtual, GrEffect
assumed the input color will be read and have a protected method for effects
that know they won't read their input to call to signal such. Or if you want to
posit that the virtual pattern is better I'm not opposed to changing the others.
I mostly would just like to keep them consistent.

[Kimmo Kinnunen, 2013-10-21 13:28:24]

On 2013/10/18 14:10:16, bsalomon wrote:
> Kimmo, sorry letting this fall off my radar! One small request: can
> willUseInputColor be made more consistent with willReadDstColor and
> willReadFragmentPosition? What I mean is that rather than a virtual, GrEffect
> assumed the input color will be read and have a protected method for effects
> that know they won't read their input to call to signal such. Or if you want
to
> posit that the virtual pattern is better I'm not opposed to changing the
others.
> I mostly would just like to keep them consistent.

Done. Typically I have used virtuals for polymorphism, but since I don't
understand 100% what was the intention with the bools, I didn't change the
existing pattern.

[bsalomon, 2013-10-21 13:39:21]

On 2013/10/21 13:28:24, kkinnunen wrote:
> On 2013/10/18 14:10:16, bsalomon wrote:
> > Kimmo, sorry letting this fall off my radar! One small request: can
> > willUseInputColor be made more consistent with willReadDstColor and
> > willReadFragmentPosition? What I mean is that rather than a virtual,
GrEffect
> > assumed the input color will be read and have a protected method for effects
> > that know they won't read their input to call to signal such. Or if you want
> to
> > posit that the virtual pattern is better I'm not opposed to changing the
> others.
> > I mostly would just like to keep them consistent.
> 
> Done. Typically I have used virtuals for polymorphism, but since I don't
> understand 100% what was the intention with the bools, I didn't change the
> existing pattern.

The idea was that some of the getters may be called multiple times in a drawing
sequence so it might be more efficient to make effects compute the answer once
in their constructor and then skip virtual function call overhead when the
getters are called.

lgtm, I've submitted a try job to see if any GMs will require rebaselining.

[commit-bot: I haz the power, 2013-10-22 20:52:35]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/kkinnunen@nvidia.com/25023003/98001

[commit-bot: I haz the power, 2013-10-23 05:41:36]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/kkinnunen@nvidia.com/25023003/98001

[commit-bot: I haz the power, 2013-10-23 05:42:12]

Change committed as 11912

[Stephen White, 2013-10-23 14:11:30]

Annoying post-commit drive-by:

"An effect with GrEffect::willUseInputColor() true will cause all color
or coverage effects before it to be discarded, as their computations
cannot affect the output."

Did you mean "false"?

[mtklein, 2013-10-23 15:41:41]

On 2013/10/23 14:11:30, Stephen White wrote:
> Annoying post-commit drive-by:
> 
> "An effect with GrEffect::willUseInputColor() true will cause all color
> or coverage effects before it to be discarded, as their computations
> cannot affect the output."
> 
> Did you mean "false"?

After this CL, I'm seeing the GLPrograms test assert:

$ out/Debug/tests --match GLPrograms
Non-default runtime configuration options:
Skia UnitTests: --match GLPrograms SK_DEBUG SK_SCALAR_IS_FLOAT
skia_arch_width=64
[  1/  1] (1) GLPrograms
../../src/effects/SkColorFilters.cpp:227: failed assertion
"SkXfermode::kDst_Mode != mode"
...

/ssd/skia/trunk/out/Debug/../../src/effects/SkColorFilters.cpp:227(_ZN21ModeColorFilterEffect8GLEffect8emitCodeEP17GrGLShaderBuilderRK12GrDrawEffectjPKcS7_RK8SkTArrayIN18GrGLProgramEffects17TransformedCoordsELb0EERKS8_INS9_14TextureSamplerELb0EE)[0x5434ba]
/ssd/skia/trunk/out/Debug/../../src/gpu/gl/GrGLProgramEffects.cpp:293(_ZN24GrGLVertexProgramEffects10emitEffectEP21GrGLFullShaderBuilderRK13GrEffectStagejPKcS6_i)[0x6e78ad]
/ssd/skia/trunk/out/Debug/../../src/gpu/gl/GrGLProgramEffects.cpp:468(_ZN31GrGLVertexProgramEffectsBuilder10emitEffectERK13GrEffectStagejPKcS4_i)[0x6e866d]
/ssd/skia/trunk/out/Debug/../../src/gpu/gl/GrGLShaderBuilder.cpp:552(_ZN17GrGLShaderBuilder20createAndEmitEffectsEP25GrGLProgramEffectsBuilderPPK13GrEffectStagePKjiP11GrGLSLExpr4)[0x6ef1a0]
/ssd/skia/trunk/out/Debug/../../src/gpu/gl/GrGLShaderBuilder.cpp:850(_ZN21GrGLFullShaderBuilder20createAndEmitEffectsEPPK13GrEffectStagePKjiP11GrGLSLExpr4)[0x6f0961]
/ssd/skia/trunk/out/Debug/../../src/gpu/gl/GrGLProgram.cpp:123(_ZN11GrGLProgram10genProgramEP17GrGLShaderBuilderPPK13GrEffectStageS5_)[0x6e317e]
/ssd/skia/trunk/out/Debug/../../src/gpu/gl/GrGLProgram.cpp:55(GrGLProgram)[0x6e2bf5]
/ssd/skia/trunk/out/Debug/../../src/gpu/gl/GrGLProgram.cpp:29(_ZN11GrGLProgram6CreateEP7GrGpuGLRK15GrGLProgramDescPPK13GrEffectStageS8_)[0x6e298e]
/ssd/skia/trunk/out/Debug/../../tests/GLProgramsTest.cpp:218(_ZN7GrGpuGL15programUnitTestEi)[0x455dae]
/ssd/skia/trunk/out/Debug/../../tests/GLProgramsTest.cpp:241(GLProgramsTest)[0x455fba]
/ssd/skia/trunk/out/Debug/../../tests/GLProgramsTest.cpp:247(_ZN8skiatest19GLProgramsTestClass5onRunEPNS_8ReporterE)[0x45692b]
/ssd/skia/trunk/out/Debug/../../tests/Test.cpp:110(_ZN8skiatest4Test3runEv)[0x4cd162]
/ssd/skia/trunk/out/Debug/../../tests/skia_test.cpp:156(_ZN14SkTestRunnable3runEv)[0x4c2aee]
/ssd/skia/trunk/out/Debug/../../tests/skia_test.cpp:245(_Z9tool_mainiPPc)[0x4c2014]
/ssd/skia/trunk/out/Debug/../../tests/skia_test.cpp:277(main)[0x4c2205]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f29b492e76d]
??:0(_start)[0x406849]

Thoughts on who's best to handle?

[bsalomon, 2013-10-23 15:45:00]

On 2013/10/23 15:41:41, mtklein wrote:
> On 2013/10/23 14:11:30, Stephen White wrote:
> > Annoying post-commit drive-by:
> > 
> > "An effect with GrEffect::willUseInputColor() true will cause all color
> > or coverage effects before it to be discarded, as their computations
> > cannot affect the output."
> > 
> > Did you mean "false"?
> 
> After this CL, I'm seeing the GLPrograms test assert:
> 
> $ out/Debug/tests --match GLPrograms
> Non-default runtime configuration options:
> Skia UnitTests: --match GLPrograms SK_DEBUG SK_SCALAR_IS_FLOAT
> skia_arch_width=64
> [  1/  1] (1) GLPrograms
> ../../src/effects/SkColorFilters.cpp:227: failed assertion
> "SkXfermode::kDst_Mode != mode"
> ...
> 
>
/ssd/skia/trunk/out/Debug/../../src/effects/SkColorFilters.cpp:227(_ZN21ModeColorFilterEffect8GLEffect8emitCodeEP17GrGLShaderBuilderRK12GrDrawEffectjPKcS7_RK8SkTArrayIN18GrGLProgramEffects17TransformedCoordsELb0EERKS8_INS9_14TextureSamplerELb0EE)[0x5434ba]
>
/ssd/skia/trunk/out/Debug/../../src/gpu/gl/GrGLProgramEffects.cpp:293(_ZN24GrGLVertexProgramEffects10emitEffectEP21GrGLFullShaderBuilderRK13GrEffectStagejPKcS6_i)[0x6e78ad]
>
/ssd/skia/trunk/out/Debug/../../src/gpu/gl/GrGLProgramEffects.cpp:468(_ZN31GrGLVertexProgramEffectsBuilder10emitEffectERK13GrEffectStagejPKcS4_i)[0x6e866d]
>
/ssd/skia/trunk/out/Debug/../../src/gpu/gl/GrGLShaderBuilder.cpp:552(_ZN17GrGLShaderBuilder20createAndEmitEffectsEP25GrGLProgramEffectsBuilderPPK13GrEffectStagePKjiP11GrGLSLExpr4)[0x6ef1a0]
>
/ssd/skia/trunk/out/Debug/../../src/gpu/gl/GrGLShaderBuilder.cpp:850(_ZN21GrGLFullShaderBuilder20createAndEmitEffectsEPPK13GrEffectStagePKjiP11GrGLSLExpr4)[0x6f0961]
>
/ssd/skia/trunk/out/Debug/../../src/gpu/gl/GrGLProgram.cpp:123(_ZN11GrGLProgram10genProgramEP17GrGLShaderBuilderPPK13GrEffectStageS5_)[0x6e317e]
>
/ssd/skia/trunk/out/Debug/../../src/gpu/gl/GrGLProgram.cpp:55(GrGLProgram)[0x6e2bf5]
>
/ssd/skia/trunk/out/Debug/../../src/gpu/gl/GrGLProgram.cpp:29(_ZN11GrGLProgram6CreateEP7GrGpuGLRK15GrGLProgramDescPPK13GrEffectStageS8_)[0x6e298e]
>
/ssd/skia/trunk/out/Debug/../../tests/GLProgramsTest.cpp:218(_ZN7GrGpuGL15programUnitTestEi)[0x455dae]
>
/ssd/skia/trunk/out/Debug/../../tests/GLProgramsTest.cpp:241(GLProgramsTest)[0x455fba]
>
/ssd/skia/trunk/out/Debug/../../tests/GLProgramsTest.cpp:247(_ZN8skiatest19GLProgramsTestClass5onRunEPNS_8ReporterE)[0x45692b]
>
/ssd/skia/trunk/out/Debug/../../tests/Test.cpp:110(_ZN8skiatest4Test3runEv)[0x4cd162]
>
/ssd/skia/trunk/out/Debug/../../tests/skia_test.cpp:156(_ZN14SkTestRunnable3runEv)[0x4c2aee]
>
/ssd/skia/trunk/out/Debug/../../tests/skia_test.cpp:245(_Z9tool_mainiPPc)[0x4c2014]
> /ssd/skia/trunk/out/Debug/../../tests/skia_test.cpp:277(main)[0x4c2205]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)[0x7f29b492e76d]
> ??:0(_start)[0x406849]
> 
> Thoughts on who's best to handle?

I can take a look.

[Kimmo Kinnunen, 2013-10-24 05:47:21]

On 2013/10/23 15:41:41, mtklein wrote:
> On 2013/10/23 14:11:30, Stephen White wrote:
> > Annoying post-commit drive-by:
> > 
> > "An effect with GrEffect::willUseInputColor() true will cause all color
> > or coverage effects before it to be discarded, as their computations
> > cannot affect the output."
> > 
> > Did you mean "false"?

Yeah, correct.
 
> 
> After this CL, I'm seeing the GLPrograms test assert:
> 
> $ out/Debug/tests --match GLPrograms
> Non-default runtime configuration options:
> Skia UnitTests: --match GLPrograms SK_DEBUG SK_SCALAR_IS_FLOAT
> skia_arch_width=64
> [  1/  1] (1) GLPrograms
> ../../src/effects/SkColorFilters.cpp:227: failed assertion
> "SkXfermode::kDst_Mode != mode"

The assertion is fixed in:
https://codereview.chromium.org/39403002/

Sorry about the mess.