Expose if we are using swiftshader via WebGraphicsContext3DProvider.

Expose if we are using swiftshader via WebGraphicsContext3DProvider.

When we are using swiftshader, we are able to make contexts but the
compositor will not use GPU compositing, and WebGL/Canvas should not
be producing GL outputs for it. This is visible via the GPUInfo's
software_rendering flag. Currently WebGL and Canvas get this info
via two different paths, and the compositor makes its decision via
a third. They all end up being the same thing (mostly not racey) but
we can make this more common by just having them all check
|software_rendering|.

This has the additional benefits that:
1) We don't need to do a round trip thru the compositor thread to
determine if we're doing GPU compositing (no more RendererCapability
needed).
2) We don't need a separate method on the Platform API.
3) Canvas2D doesn't have a semi-racey thing where it can check
|software_rendering| on one GpuChannelHost, lose it, then make a
context on a different GpuChannelHost. Now the capability is explicitly
tied to the lifetime of the context, which is what the comment in
Platform tried to warn about.
4) Additionally, have DrawingBuffer check lost context and not try
to produce frames in this scenario since it may end up producing the
wrong mode for the compositor which is already using a new context
with a different mode. (Canvas already does this.)

This helps us eliminate races between cc/webgl/canvas on
making this decision. When the GpuChannelHost is lost, all contexts
become lost when the next code tries to create a context. Since we
now tie the decisions around which mode to use to the context, and
the context is lost when any other part of the system would change
its opinion about what mode to use, they should all agree.

[email protected], [email protected], [email protected]
BUG=606056
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel

Committed: https://crrev.com/4dd43951b9efedb9473e65e8132ee5d8976bc860
Cr-Commit-Position: refs/heads/master@{#413837}

[danakj, 2016-08-22 21:49:51]

[email protected] changed reviewers:
+ [email protected]

[danakj, 2016-08-22 21:49:52]

+pdr for public/ again

[danakj, 2016-08-22 21:54:05]

kbr: please review webgl bits
junov: please review canvas bits
piman: please review content/ and my no-more-races GpuChannelHost logic

[danakj, 2016-08-22 21:54:32]

(I'll remove the useSharedMemory parameter from PrepareTextureMailbox in a
followup CL)

[Ken Russell (switch to Gerrit), 2016-08-22 22:03:16]

Very nice. LGTM

[pdr., 2016-08-22 22:05:41]

On 2016/08/22 at 21:49:52, danakj wrote:
> +pdr for public/ again

LGTM for public/

[piman, 2016-08-22 22:39:51]

lgtm

https://codereview.chromium.org/2267993002/diff/20001/content/renderer/render...
File content/renderer/renderer_blink_platform_impl.cc (right):

https://codereview.chromium.org/2267993002/diff/20001/content/renderer/render...
content/renderer/renderer_blink_platform_impl.cc:1133: //
|is_software_rendering| will never be wrong.
Alternatively, we could grab the host from |provider|, to make sure everything
is consistent.

[danakj, 2016-08-22 22:54:11]

Description was changed from

==========
Expose if we are using swiftshader via WebGraphicsContext3DProvider.

When we are using swiftshader, we are able to make contexts but the
compositor will not use GPU compositing, and WebGL/Canvas should not
be producing GL outputs for it. This is visible via the GPUInfo's
software_rendering flag. Currently WebGL and Canvas get this info
via two different paths, and the compositor makes its decision via
a third. They all end up being the same thing (mostly not racey) but
we can make this more common by just having them all check
|software_rendering|.

This has the additional benefits that:
1) We don't need to do a round trip thru the compositor thread to
determine if we're doing GPU compositing (no more RendererCapability
needed).
2) We don't need a separate method on the Platform API.
3) Canvas2D doesn't have a semi-racey thing where it can check
|software_rendering| on one GpuChannelHost, lose it, then make a
context on a different GpuChannelHost. Now the capability is explicitly
tied to the lifetime of the context, which is what the comment in
Platform tried to warn about.
4) Additionally, have DrawingBuffer check lost context and not try
to produce frames in this scenario since it may end up producing the
wrong mode for the compositor which is already using a new context
with a different mode. (Canvas already does this.)

This helps us eliminate races between cc/webgl/canvas on
making this decision. When the GpuChannelHost is lost, all contexts
become lost when the next code tries to create a context. Since we
now tie the decisions around which mode to use to the context, and
the context is lost when any other part of the system would change
its opinion about what mode to use, they should all agree.

[email protected], [email protected], [email protected]
BUG=606056
==========

to

==========
Expose if we are using swiftshader via WebGraphicsContext3DProvider.

When we are using swiftshader, we are able to make contexts but the
compositor will not use GPU compositing, and WebGL/Canvas should not
be producing GL outputs for it. This is visible via the GPUInfo's
software_rendering flag. Currently WebGL and Canvas get this info
via two different paths, and the compositor makes its decision via
a third. They all end up being the same thing (mostly not racey) but
we can make this more common by just having them all check
|software_rendering|.

This has the additional benefits that:
1) We don't need to do a round trip thru the compositor thread to
determine if we're doing GPU compositing (no more RendererCapability
needed).
2) We don't need a separate method on the Platform API.
3) Canvas2D doesn't have a semi-racey thing where it can check
|software_rendering| on one GpuChannelHost, lose it, then make a
context on a different GpuChannelHost. Now the capability is explicitly
tied to the lifetime of the context, which is what the comment in
Platform tried to warn about.
4) Additionally, have DrawingBuffer check lost context and not try
to produce frames in this scenario since it may end up producing the
wrong mode for the compositor which is already using a new context
with a different mode. (Canvas already does this.)

This helps us eliminate races between cc/webgl/canvas on
making this decision. When the GpuChannelHost is lost, all contexts
become lost when the next code tries to create a context. Since we
now tie the decisions around which mode to use to the context, and
the context is lost when any other part of the system would change
its opinion about what mode to use, they should all agree.

[email protected], [email protected], [email protected]
BUG=606056
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
==========

[danakj, 2016-08-22 22:54:23]

Patchset #3 (id:40001) has been deleted

[danakj, 2016-08-22 22:57:44]

2 lil changes in the last patchset.

https://codereview.chromium.org/2267993002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.cpp
(right):

https://codereview.chromium.org/2267993002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/graphics/Canvas2DLayerBridge.cpp:795: // If
the context is lost, we don't know if we should be producing GPU or
I made Canvas2DLB check for context loss explicitly, and return false in this
case, so it's not going to ever give to cc a GPU frame when cc has already
switched to using software. This matches DrawingBuffer.

https://codereview.chromium.org/2267993002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp (right):

https://codereview.chromium.org/2267993002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/graphics/gpu/DrawingBuffer.cpp:272: bool
DrawingBuffer::prepareTextureMailboxInternal(
I added a prepareTextureMailboxInternal that lets the caller force a gpu mailbox
result even under swiftshader, for the transferToStaticBitmapImage to use.

[Ken Russell (switch to Gerrit), 2016-08-22 23:25:03]

Thanks for tracking down the transferToStaticBitmapImage issue. Still LGTM.

[danakj, 2016-08-22 23:42:49]

The CQ bit was checked by [email protected] to run a CQ dry run

[commit-bot: I haz the power, 2016-08-22 23:43:34]

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

[danakj, 2016-08-23 01:02:30]

junov: I'll wait for your review of the canvas stuff, thanks :)

[commit-bot: I haz the power, 2016-08-23 03:43:17]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2016-08-23 03:43:19]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[danakj, 2016-08-23 17:11:46]

The CQ bit was checked by [email protected] to run a CQ dry run

[commit-bot: I haz the power, 2016-08-23 17:12:35]

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

[danakj, 2016-08-23 21:02:21]

The CQ bit was unchecked by [email protected]

[danakj, 2016-08-23 21:02:31]

The CQ bit was checked by [email protected] to run a CQ dry run

[commit-bot: I haz the power, 2016-08-23 21:03:42]

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

[Justin Novosad, 2016-08-23 21:08:04]

On 2016/08/23 01:02:30, danakj wrote:
> junov: I'll wait for your review of the canvas stuff, thanks :)

lgtm

[commit-bot: I haz the power, 2016-08-23 21:08:51]

The CQ bit was unchecked by [email protected]

[commit-bot: I haz the power, 2016-08-23 21:08:53]

Dry run: This issue passed the CQ dry run.

[danakj, 2016-08-23 21:11:33]

The CQ bit was unchecked by [email protected]

[danakj, 2016-08-23 21:11:39]

The CQ bit was checked by [email protected]

[danakj, 2016-08-23 21:11:39]

The patchset sent to the CQ was uploaded after l-g-t-m from [email protected],
[email protected]
Link to the patchset: https://codereview.chromium.org/2267993002/#ps60001
(title: "softwarerendering: .")

[commit-bot: I haz the power, 2016-08-23 21:12:47]

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-08-23 21:19:01]

Committed patchset #3 (id:60001)

[commit-bot: I haz the power, 2016-08-23 21:20:43]

Description was changed from

==========
Expose if we are using swiftshader via WebGraphicsContext3DProvider.

When we are using swiftshader, we are able to make contexts but the
compositor will not use GPU compositing, and WebGL/Canvas should not
be producing GL outputs for it. This is visible via the GPUInfo's
software_rendering flag. Currently WebGL and Canvas get this info
via two different paths, and the compositor makes its decision via
a third. They all end up being the same thing (mostly not racey) but
we can make this more common by just having them all check
|software_rendering|.

This has the additional benefits that:
1) We don't need to do a round trip thru the compositor thread to
determine if we're doing GPU compositing (no more RendererCapability
needed).
2) We don't need a separate method on the Platform API.
3) Canvas2D doesn't have a semi-racey thing where it can check
|software_rendering| on one GpuChannelHost, lose it, then make a
context on a different GpuChannelHost. Now the capability is explicitly
tied to the lifetime of the context, which is what the comment in
Platform tried to warn about.
4) Additionally, have DrawingBuffer check lost context and not try
to produce frames in this scenario since it may end up producing the
wrong mode for the compositor which is already using a new context
with a different mode. (Canvas already does this.)

This helps us eliminate races between cc/webgl/canvas on
making this decision. When the GpuChannelHost is lost, all contexts
become lost when the next code tries to create a context. Since we
now tie the decisions around which mode to use to the context, and
the context is lost when any other part of the system would change
its opinion about what mode to use, they should all agree.

[email protected], [email protected], [email protected]
BUG=606056
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel
==========

to

==========
Expose if we are using swiftshader via WebGraphicsContext3DProvider.

When we are using swiftshader, we are able to make contexts but the
compositor will not use GPU compositing, and WebGL/Canvas should not
be producing GL outputs for it. This is visible via the GPUInfo's
software_rendering flag. Currently WebGL and Canvas get this info
via two different paths, and the compositor makes its decision via
a third. They all end up being the same thing (mostly not racey) but
we can make this more common by just having them all check
|software_rendering|.

This has the additional benefits that:
1) We don't need to do a round trip thru the compositor thread to
determine if we're doing GPU compositing (no more RendererCapability
needed).
2) We don't need a separate method on the Platform API.
3) Canvas2D doesn't have a semi-racey thing where it can check
|software_rendering| on one GpuChannelHost, lose it, then make a
context on a different GpuChannelHost. Now the capability is explicitly
tied to the lifetime of the context, which is what the comment in
Platform tried to warn about.
4) Additionally, have DrawingBuffer check lost context and not try
to produce frames in this scenario since it may end up producing the
wrong mode for the compositor which is already using a new context
with a different mode. (Canvas already does this.)

This helps us eliminate races between cc/webgl/canvas on
making this decision. When the GpuChannelHost is lost, all contexts
become lost when the next code tries to create a context. Since we
now tie the decisions around which mode to use to the context, and
the context is lost when any other part of the system would change
its opinion about what mode to use, they should all agree.

[email protected], [email protected], [email protected]
BUG=606056
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel

Committed: https://crrev.com/4dd43951b9efedb9473e65e8132ee5d8976bc860
Cr-Commit-Position: refs/heads/master@{#413837}
==========

[commit-bot: I haz the power, 2016-08-23 21:20:45]

Patchset 3 (id:??) landed as
https://crrev.com/4dd43951b9efedb9473e65e8132ee5d8976bc860
Cr-Commit-Position: refs/heads/master@{#413837}