Fix darkened pixels when rendering using GPU

Fix darkened pixels when rendering using GPU

This CL fixes the issue reported in bugs 713632 and 713702, where the
pixels are darker than usual when rendered with GPU on some specific
devices.

BUG=713632
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2838153003
Cr-Commit-Position: refs/heads/master@{#467372}
Committed: https://chromium.googlesource.com/chromium/src/+/678a0bea8eb9989953ca780f6afcb382ae047aee

[zakerinasab, 2017-04-25 15:55:01]

Description was changed from

==========
Fix darkened pixels when rendering using GPU

This CL fixes the issue reported in bgus 713632 and 713702, where the
pixels are darker than usual when rendered with GPU on some specific
decives.

BUG=713632,713702
==========

to

==========
Fix darkened pixels when rendering using GPU

This CL fixes the issue reported in bgus 713632 and 713702, where the
pixels are darker than usual when rendered with GPU on some specific
decives.

BUG=713632,713702
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[zakerinasab, 2017-04-25 15:56:36]

Description was changed from

==========
Fix darkened pixels when rendering using GPU

This CL fixes the issue reported in bgus 713632 and 713702, where the
pixels are darker than usual when rendered with GPU on some specific
decives.

BUG=713632,713702
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Fix darkened pixels when rendering using GPU

This CL fixes the issue reported in bgus 713632 and 713702, where the
pixels are darker than usual when rendered with GPU on some specific
decives.

BUG=713632,713702
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[zakerinasab, 2017-04-25 15:56:36]

zakerinasab@chromium.org changed reviewers:
+ junov@chromium.org, kbr@chromium.org, vmiura@chromium.org

[zakerinasab, 2017-04-25 15:56:42]

The CQ bit was checked by zakerinasab@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-25 15:56:56]

Dry run: CQ is trying da patch.

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

[Ken Russell (switch to Gerrit), 2017-04-25 16:06:34]

Description was changed from

==========
Fix darkened pixels when rendering using GPU

This CL fixes the issue reported in bgus 713632 and 713702, where the
pixels are darker than usual when rendered with GPU on some specific
decives.

BUG=713632,713702
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Fix darkened pixels when rendering using GPU

This CL fixes the issue reported in bugs 713632 and 713702, where the
pixels are darker than usual when rendered with GPU on some specific
decives.

BUG=713632,713702
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[Ken Russell (switch to Gerrit), 2017-04-25 16:06:42]

Description was changed from

==========
Fix darkened pixels when rendering using GPU

This CL fixes the issue reported in bugs 713632 and 713702, where the
pixels are darker than usual when rendered with GPU on some specific
decives.

BUG=713632,713702
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Fix darkened pixels when rendering using GPU

This CL fixes the issue reported in bugs 713632 and 713702, where the
pixels are darker than usual when rendered with GPU on some specific
devices.

BUG=713632,713702
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[Ken Russell (switch to Gerrit), 2017-04-25 16:06:56]

+xlai as FYI

[zakerinasab, 2017-04-25 16:08:59]

For the record, bisect narrows down to this CL:
https://codereview.chromium.org/2560563002/

[Ken Russell (switch to Gerrit), 2017-04-25 16:15:01]

kbr@chromium.org changed reviewers:
+ bsalomon@chromium.org

[Ken Russell (switch to Gerrit), 2017-04-25 16:15:01]

https://codereview.chromium.org/2838153003/diff/1/gpu/command_buffer/service/...
File gpu/command_buffer/service/feature_info.cc (left):

https://codereview.chromium.org/2838153003/diff/1/gpu/command_buffer/service/...
gpu/command_buffer/service/feature_info.cc:692: }
Simply stopping the command buffer from advertising the
GL_EXT_texture_sRGB_decode extension to the renderer processes is not the
correct fix. Clearly there is an unexpected problem with the *usage* of this
extension and that's what needs to be fixed. Otherwise for example when more of
Skia is moved to the GPU process this same bug will happen again.

As far as I can tell the only use of this extension in Chrome's code base is in
Skia's Ganesh backend:
https://cs.chromium.org/chromium/src/third_party/skia/src/gpu/gl/GrGLGpu.cpp?...

You should work with the Skia team to understand why double-gamma-correction is
happening during putImageData operations. +bsalomon

Also, you could consider adding an entry to
src/gpu/config/gpu_driver_bug_list.json which uses the disabled_extensions
section to disable the GL_EXT_texture_sRGB_decode extension, referring to one or
more of these bugs, with the intent to remove the bug entry as soon as the root
cause is known and fixed.

[bsalomon_chromium, 2017-04-25 16:18:21]

bsalomon@chromium.org changed reviewers:
+ brianosman@chromium.org

[bsalomon_chromium, 2017-04-25 16:18:39]

On 2017/04/25 16:15:01, Ken Russell wrote:
>
https://codereview.chromium.org/2838153003/diff/1/gpu/command_buffer/service/...
> File gpu/command_buffer/service/feature_info.cc (left):
> 
>
https://codereview.chromium.org/2838153003/diff/1/gpu/command_buffer/service/...
> gpu/command_buffer/service/feature_info.cc:692: }
> Simply stopping the command buffer from advertising the
> GL_EXT_texture_sRGB_decode extension to the renderer processes is not the
> correct fix. Clearly there is an unexpected problem with the *usage* of this
> extension and that's what needs to be fixed. Otherwise for example when more
of
> Skia is moved to the GPU process this same bug will happen again.
> 
> As far as I can tell the only use of this extension in Chrome's code base is
in
> Skia's Ganesh backend:
>
https://cs.chromium.org/chromium/src/third_party/skia/src/gpu/gl/GrGLGpu.cpp?...
> 
> You should work with the Skia team to understand why double-gamma-correction
is
> happening during putImageData operations. +bsalomon
> 
> Also, you could consider adding an entry to
> src/gpu/config/gpu_driver_bug_list.json which uses the disabled_extensions
> section to disable the GL_EXT_texture_sRGB_decode extension, referring to one
or
> more of these bugs, with the intent to remove the bug entry as soon as the
root
> cause is known and fixed.

+brianosman for srgb

[zakerinasab, 2017-04-25 16:43:44]

The CQ bit was checked by zakerinasab@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-25 16:44:16]

Dry run: CQ is trying da patch.

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

[Ken Russell (switch to Gerrit), 2017-04-25 16:45:14]

lgtm

[zakerinasab, 2017-04-25 16:45:46]

I added the sRGB decode extension to the exception list in
	gpu/config/gpu_driver_bug_list.json and filed a Skia bug for more
investigation: https://bugs.chromium.org/p/skia/issues/detail?id=6547.

https://codereview.chromium.org/2838153003/diff/1/gpu/command_buffer/service/...
File gpu/command_buffer/service/feature_info.cc (left):

https://codereview.chromium.org/2838153003/diff/1/gpu/command_buffer/service/...
gpu/command_buffer/service/feature_info.cc:692: }
On 2017/04/25 16:15:01, Ken Russell wrote:
> Simply stopping the command buffer from advertising the
> GL_EXT_texture_sRGB_decode extension to the renderer processes is not the
> correct fix. Clearly there is an unexpected problem with the *usage* of this
> extension and that's what needs to be fixed. Otherwise for example when more
of
> Skia is moved to the GPU process this same bug will happen again.
> 
> As far as I can tell the only use of this extension in Chrome's code base is
in
> Skia's Ganesh backend:
>
https://cs.chromium.org/chromium/src/third_party/skia/src/gpu/gl/GrGLGpu.cpp?...
> 
> You should work with the Skia team to understand why double-gamma-correction
is
> happening during putImageData operations. +bsalomon
> 
> Also, you could consider adding an entry to
> src/gpu/config/gpu_driver_bug_list.json which uses the disabled_extensions
> section to disable the GL_EXT_texture_sRGB_decode extension, referring to one
or
> more of these bugs, with the intent to remove the bug entry as soon as the
root
> cause is known and fixed.

Done.

[zakerinasab, 2017-04-25 16:50:45]

Description was changed from

==========
Fix darkened pixels when rendering using GPU

This CL fixes the issue reported in bugs 713632 and 713702, where the
pixels are darker than usual when rendered with GPU on some specific
devices.

BUG=713632,713702
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Fix darkened pixels when rendering using GPU

This CL fixes the issue reported in bugs 713632 and 713702, where the
pixels are darker than usual when rendered with GPU on some specific
devices.

BUG=713632
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

[zakerinasab, 2017-04-25 17:24:42]

The CQ bit was unchecked by zakerinasab@chromium.org

[zakerinasab, 2017-04-25 17:24:43]

The CQ bit was checked by zakerinasab@chromium.org

[commit-bot: I haz the power, 2017-04-25 17:25:00]

CQ is trying da patch.

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

[Justin Novosad, 2017-04-25 17:26:29]

I have a more fundamental question: Why is this extension kicking in at all when
the "color correct rendering" feature is disabled?  It sounds to me like Blink
is tagging skia things with color spaces in cases where it should not.  If we
leave SkImages and SkSurfaces untagged, skia should not be triggering any color
management.

[Justin Novosad, 2017-04-25 17:27:11]

The CQ bit was unchecked by junov@chromium.org

[Brian Osman, 2017-04-25 17:32:06]

On 2017/04/25 17:26:29, junov - OoO - back April 24 wrote:
> I have a more fundamental question: Why is this extension kicking in at all
when
> the "color correct rendering" feature is disabled?  It sounds to me like Blink
> is tagging skia things with color spaces in cases where it should not.  If we
> leave SkImages and SkSurfaces untagged, skia should not be triggering any
color
> management.

My understanding is that the command buffer now exposes several sRGB extensions,
regardless of being in "color correct" mode. Skia (attempts to) suppress all
sRGB
functionality unless SkSurfaces are tagged, but this was one case where that
wasn't
true.

[vmiura, 2017-04-25 18:10:29]

On 2017/04/25 17:32:06, Brian Osman wrote:
> On 2017/04/25 17:26:29, junov - OoO - back April 24 wrote:
> > I have a more fundamental question: Why is this extension kicking in at all
> when
> > the "color correct rendering" feature is disabled?  It sounds to me like
Blink
> > is tagging skia things with color spaces in cases where it should not.  If
we
> > leave SkImages and SkSurfaces untagged, skia should not be triggering any
> color
> > management.
> 
> My understanding is that the command buffer now exposes several sRGB
extensions,
> regardless of being in "color correct" mode. Skia (attempts to) suppress all
> sRGB
> functionality unless SkSurfaces are tagged, but this was one case where that
> wasn't
> true.

This LGTM as a quick fix but the problem must be that we're enabling sRGB mode
where we shouldn't be.

[zakerinasab, 2017-04-25 18:24:31]

On 2017/04/25 18:10:29, vmiura wrote:
> On 2017/04/25 17:32:06, Brian Osman wrote:
> > On 2017/04/25 17:26:29, junov - OoO - back April 24 wrote:
> > > I have a more fundamental question: Why is this extension kicking in at
all
> > when
> > > the "color correct rendering" feature is disabled?  It sounds to me like
> Blink
> > > is tagging skia things with color spaces in cases where it should not.  If
> we
> > > leave SkImages and SkSurfaces untagged, skia should not be triggering any
> > color
> > > management.
> > 
> > My understanding is that the command buffer now exposes several sRGB
> extensions,
> > regardless of being in "color correct" mode. Skia (attempts to) suppress all
> > sRGB
> > functionality unless SkSurfaces are tagged, but this was one case where that
> > wasn't
> > true.
> 
> This LGTM as a quick fix but the problem must be that we're enabling sRGB mode
> where we shouldn't be.

You're right. I'm preparing a new fix in that direction now.

[zakerinasab, 2017-04-25 18:53:59]

The CQ bit was checked by zakerinasab@chromium.org to run a CQ dry run

[zakerinasab, 2017-04-25 18:54:44]

New CL uploaded doing a quick fix in ImageBuffer.cpp and adding a pixel test to
avoid the problem in future (until color managed canvas is shipped).

[commit-bot: I haz the power, 2017-04-25 18:54:59]

Dry run: CQ is trying da patch.

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

[msarett1, 2017-04-25 19:06:58]

On 2017/04/25 18:54:44, zakerinasab wrote:
> New CL uploaded doing a quick fix in ImageBuffer.cpp and adding a pixel test
to
> avoid the problem in future (until color managed canvas is shipped).

I think this is fine as a workaround... but is only necessary because of a Skia
bug and generally not the right direction to move in.  Paraphrasing from
skbug.com/6547:

Skia should not have any color correct behavior as long as the "dst" is nullptr.
 "srcs" should always be tagged - then the dst can be changed to alter between
various Skia modes, ex: legacy, legacy++ (inputs pre-converted to dst), fully
color correct.

[Justin Novosad, 2017-04-25 22:12:21]

Even now that the skia issue is fixed, I think this CL should still land. The
change to ImageBuffer makes sense even though it is no longer strictly required.
 Also, adding an end-to-end test (on to of the test that was added to skia)
makes sense considering we will be enabling color correct rendering soon.

lgtm

[Ken Russell (switch to Gerrit), 2017-04-25 22:28:55]

Good work adding a test for this, but a question about it.

https://codereview.chromium.org/2838153003/diff/40001/content/test/data/gpu/p...
File content/test/data/gpu/pixel_canvas2d_untagged.html (right):

https://codereview.chromium.org/2838153003/diff/40001/content/test/data/gpu/p...
content/test/data/gpu/pixel_canvas2d_untagged.html:27: ctx.putImageData(image,
0, 0);
With the bug present, was there a change in the round-trip data if putImageData
was followed by getImageData?

If so, then this bug is visible to JavaScript (not just the compositor), and a
layout test would be more appropriate.

[chromium-reviews, 2017-04-25 22:58:22]

Yes, the bug is visible in a put/getImageData round-trip. We need a pixel
test since apparently layout tests do not run on Android try bots. I can
add a layout test too if it's ​needed.

On Apr 25, 2017 6:28 PM, <kbr@chromium.org> wrote:

Good work adding a test for this, but a question about it.



https://codereview.chromium.org/2838153003/diff/40001/
content/test/data/gpu/pixel_canvas2d_untagged.html
File content/test/data/gpu/pixel_canvas2d_untagged.html (right):

https://codereview.chromium.org/2838153003/diff/40001/
content/test/data/gpu/pixel_canvas2d_untagged.html#newcode27
content/test/data/gpu/pixel_canvas2d_untagged.html:27:
ctx.putImageData(image, 0, 0);
With the bug present, was there a change in the round-trip data if
putImageData was followed by getImageData?

If so, then this bug is visible to JavaScript (not just the compositor),
and a layout test would be more appropriate.

https://codereview.chromium.org/2838153003/

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Ken Russell (switch to Gerrit), 2017-04-25 23:24:20]

On 2017/04/25 22:58:22, chromium-reviews wrote:
> Yes, the bug is visible in a put/getImageData round-trip. We need a pixel
> test since apparently layout tests do not run on Android try bots. I can
> add a layout test too if it's ​needed.

Ah, I see.

Yes, I recommend adding a layout test for this too. I'm not sure of the status
of running layout tests on the Android trybots -- recommend asking jbudorick@ or
dpranke@ -- but that's the most direct way to test this.

[commit-bot: I haz the power, 2017-04-25 23:45:21]

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

[commit-bot: I haz the power, 2017-04-25 23:45:22]

Dry run: This issue passed the CQ dry run.

[zakerinasab, 2017-04-26 04:48:10]

On 2017/04/25 23:24:20, Ken Russell wrote:
> On 2017/04/25 22:58:22, chromium-reviews wrote:
> > Yes, the bug is visible in a put/getImageData round-trip. We need a pixel
> > test since apparently layout tests do not run on Android try bots. I can
> > add a layout test too if it's ​needed.
> 
> Ah, I see.
> 
> Yes, I recommend adding a layout test for this too. I'm not sure of the status
> of running layout tests on the Android trybots -- recommend asking jbudorick@
or
> dpranke@ -- but that's the most direct way to test this.

We have round-trip layout tests for ImageData, but the canvas size is 200 by
200.
I added a simple layout test with canvas size of 257 by 257 to use the GPU path.

[zakerinasab, 2017-04-26 04:48:21]

The CQ bit was checked by zakerinasab@chromium.org

[zakerinasab, 2017-04-26 04:48:21]

The patchset sent to the CQ was uploaded after l-g-t-m from kbr@chromium.org,
vmiura@chromium.org, junov@chromium.org
Link to the patchset: https://codereview.chromium.org/2838153003/#ps60001
(title: "Adding layout test")

[commit-bot: I haz the power, 2017-04-26 04:48:42]

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, 2017-04-26 06:02:12]

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

[commit-bot: I haz the power, 2017-04-26 06:02:14]

Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[zakerinasab, 2017-04-26 13:34:19]

The CQ bit was checked by zakerinasab@chromium.org

[zakerinasab, 2017-04-26 13:34:20]

The patchset sent to the CQ was uploaded after l-g-t-m from kbr@chromium.org,
junov@chromium.org, vmiura@chromium.org
Link to the patchset: https://codereview.chromium.org/2838153003/#ps80001
(title: "Rebaseline")

[commit-bot: I haz the power, 2017-04-26 13:34:34]

CQ is trying da patch.

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

[Justin Novosad, 2017-04-26 13:40:04]

On 2017/04/26 04:48:10, zakerinasab wrote:
> On 2017/04/25 23:24:20, Ken Russell wrote:
> > On 2017/04/25 22:58:22, chromium-reviews wrote:
> > > Yes, the bug is visible in a put/getImageData round-trip. We need a pixel
> > > test since apparently layout tests do not run on Android try bots. I can
> > > add a layout test too if it's ​needed.
> > 
> > Ah, I see.
> > 
> > Yes, I recommend adding a layout test for this too. I'm not sure of the
status
> > of running layout tests on the Android trybots -- recommend asking
jbudorick@
> or
> > dpranke@ -- but that's the most direct way to test this.
> 
> We have round-trip layout tests for ImageData, but the canvas size is 200 by
> 200.
> I added a simple layout test with canvas size of 257 by 257 to use the GPU
path.

Canvas size does not matter in layout tests  under virtual/gpu/ all canvases are
rendered on the GPU, regardless of size.

[Justin Novosad, 2017-04-26 13:40:15]

The CQ bit was unchecked by junov@chromium.org

[zakerinasab, 2017-04-26 14:11:18]

The CQ bit was checked by zakerinasab@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-04-26 14:11:33]

Dry run: CQ is trying da patch.

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

[zakerinasab, 2017-04-26 14:28:51]

Patchset #6 (id:100001) has been deleted

[zakerinasab, 2017-04-26 15:31:52]

The CQ bit was checked by zakerinasab@chromium.org

[zakerinasab, 2017-04-26 15:31:52]

The patchset sent to the CQ was uploaded after l-g-t-m from kbr@chromium.org,
junov@chromium.org, vmiura@chromium.org
Link to the patchset: https://codereview.chromium.org/2838153003/#ps120001
(title: "Removing unneeded layout-test")

[commit-bot: I haz the power, 2017-04-26 15:32:12]

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, 2017-04-26 17:50:32]

CQ is committing da patch.

Bot data: {"patchset_id": 120001, "attempt_start_ts": 1493220712321880,
"parent_rev": "fb89a91b264ad2c6bad9acd32aeb42c45b6f1e69", "commit_rev":
"678a0bea8eb9989953ca780f6afcb382ae047aee"}

[commit-bot: I haz the power, 2017-04-26 17:50:40]

Description was changed from

==========
Fix darkened pixels when rendering using GPU

This CL fixes the issue reported in bugs 713632 and 713702, where the
pixels are darker than usual when rendered with GPU on some specific
devices.

BUG=713632
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel
==========

to

==========
Fix darkened pixels when rendering using GPU

This CL fixes the issue reported in bugs 713632 and 713702, where the
pixels are darker than usual when rendered with GPU on some specific
devices.

BUG=713632
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_optional_gpu_tests_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel

Review-Url: https://codereview.chromium.org/2838153003
Cr-Commit-Position: refs/heads/master@{#467372}
Committed:
https://chromium.googlesource.com/chromium/src/+/678a0bea8eb9989953ca780f6afc...
==========

[commit-bot: I haz the power, 2017-04-26 17:50:41]

Committed patchset #6 (id:120001) as
https://chromium.googlesource.com/chromium/src/+/678a0bea8eb9989953ca780f6afc...