Revert of Report lost context from GLES2Implementation based on share group state.

Revert of Report lost context from GLES2Implementation based on share group state. (patchset #3 id:40001 of https://codereview.chromium.org/1916303003/ )

Reason for revert:
Seems to be crashing tests. See two attached bugs:

1. BrowserGpuChannelHostFactoryTest crashes in GPU-related code. DCHECK(IsContextLost(context_provider->ContextGL())) is failing in the second stack trace, which leads me to this CL. https://crbug.com/607048.
2. virtual/gpu/fast/canvas/canvas-lost-gpu-context.html LayoutTest is failing with "Graphics context loss did not destroy canvas contents." The mention of context loss also leads me to this CL. https://crbug.com/607049.

Speculatively reverting.

BUG=607048, 607049
Original issue's description:
> Report lost context from GLES2Implementation based on share group state.
>
> When any context in a gles2::ShareGroup becomes lost, all contexts in
> the same group should report that they are lost immediately. This avoids
> races such as the following:
>
> IPC thread hears of the loss of Context 1 and 2.
> IPC thread posts to thread B for Context 1.
> Context 1 hears it is lost on thread B. Posts to thread A to recreate.
> IPC thread posts to thread A for Context 2.
> Context 1 is recreated on thread A. Puts itself in same share group as 2.
> Context 2 hears it is lost on thread A, makes a new share group.
>
> This can lead to racey cases where share groups get split apart.
>
> Resolve this by storing a |lost_| state on gles2::ShareGroup. When
> GLES2Implementation hears of OnGpuControlLostContext, it will set the
> lost state on the ShareGroup. Now glGetGraphicsResetStatusKHR() will
> return an error if the gles2::ShareGroup has been lost.
>
> We remove the GpuControl::IsChannelLost() method as this is now unused.
> The CmdBufferHelper::IsContextLost() is still needed for the
> QueryTracker, so insert a comment and a TODO explaining why and how
> it could be removed.
>
> R=piman, sievers
> BUG=584497
> CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel
>
> Committed: https://crrev.com/b1f17d6f3f988d7b190cab1147b1e20da0647a44
> Cr-Commit-Position: refs/heads/master@{#389947}

TBR=piman@chromium.org,sievers@chromium.org,fsamuel@google.com,sky@chromium.org,fsamuel@chromium.org,danakj@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=584497
Committed: https://crrev.com/2cc4cad984106eeb0309f2af08a35cad6c53a59f
Cr-Commit-Position: refs/heads/master@{#389980}

[Matt Giuca, 2016-04-27 03:32:11]

Created Revert of Report lost context from GLES2Implementation based on share
group state.

[commit-bot: I haz the power, 2016-04-27 03:32:18]

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

[Matt Giuca, 2016-04-27 03:33:03]

The CQ bit was unchecked by mgiuca@chromium.org

[commit-bot: I haz the power, 2016-04-27 03:33:07]

Description was changed from

==========
Revert of Report lost context from GLES2Implementation based on share group
state. (patchset #3 id:40001 of https://codereview.chromium.org/1916303003/ )

Reason for revert:
Seems to be crashing tests. See two attached bugs:

1. BrowserGpuChannelHostFactoryTest crashes in GPU-related code.
DCHECK(IsContextLost(context_provider->ContextGL())) is failing in the second
stack trace, which leads me to this CL. https://crbug.com/607048.
2. virtual/gpu/fast/canvas/canvas-lost-gpu-context.html LayoutTest is failing
with "Graphics context loss did not destroy canvas contents." The mention of
context loss also leads me to this CL. https://crbug.com/607049.

Speculatively reverting.

BUG=607048,607049

Original issue's description:
> Report lost context from GLES2Implementation based on share group state.
> 
> When any context in a gles2::ShareGroup becomes lost, all contexts in
> the same group should report that they are lost immediately. This avoids
> races such as the following:
> 
> IPC thread hears of the loss of Context 1 and 2.
> IPC thread posts to thread B for Context 1.
> Context 1 hears it is lost on thread B. Posts to thread A to recreate.
> IPC thread posts to thread A for Context 2.
> Context 1 is recreated on thread A. Puts itself in same share group as 2.
> Context 2 hears it is lost on thread A, makes a new share group.
> 
> This can lead to racey cases where share groups get split apart.
> 
> Resolve this by storing a |lost_| state on gles2::ShareGroup. When
> GLES2Implementation hears of OnGpuControlLostContext, it will set the
> lost state on the ShareGroup. Now glGetGraphicsResetStatusKHR() will
> return an error if the gles2::ShareGroup has been lost.
> 
> We remove the GpuControl::IsChannelLost() method as this is now unused.
> The CmdBufferHelper::IsContextLost() is still needed for the
> QueryTracker, so insert a comment and a TODO explaining why and how
> it could be removed.
> 
> R=piman, sievers
> BUG=584497
>
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel
> 
> Committed: https://crrev.com/b1f17d6f3f988d7b190cab1147b1e20da0647a44
> Cr-Commit-Position: refs/heads/master@{#389947}

TBR=piman@chromium.org,sievers@chromium.org,fsamuel@google.com,sky@chromium.o...
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=584497
==========

to

==========
Revert of Report lost context from GLES2Implementation based on share group
state. (patchset #3 id:40001 of https://codereview.chromium.org/1916303003/ )

Reason for revert:
Seems to be crashing tests. See two attached bugs:

1. BrowserGpuChannelHostFactoryTest crashes in GPU-related code.
DCHECK(IsContextLost(context_provider->ContextGL())) is failing in the second
stack trace, which leads me to this CL. https://crbug.com/607048.
2. virtual/gpu/fast/canvas/canvas-lost-gpu-context.html LayoutTest is failing
with "Graphics context loss did not destroy canvas contents." The mention of
context loss also leads me to this CL. https://crbug.com/607049.

Speculatively reverting.

BUG=607048,607049

Original issue's description:
> Report lost context from GLES2Implementation based on share group state.
> 
> When any context in a gles2::ShareGroup becomes lost, all contexts in
> the same group should report that they are lost immediately. This avoids
> races such as the following:
> 
> IPC thread hears of the loss of Context 1 and 2.
> IPC thread posts to thread B for Context 1.
> Context 1 hears it is lost on thread B. Posts to thread A to recreate.
> IPC thread posts to thread A for Context 2.
> Context 1 is recreated on thread A. Puts itself in same share group as 2.
> Context 2 hears it is lost on thread A, makes a new share group.
> 
> This can lead to racey cases where share groups get split apart.
> 
> Resolve this by storing a |lost_| state on gles2::ShareGroup. When
> GLES2Implementation hears of OnGpuControlLostContext, it will set the
> lost state on the ShareGroup. Now glGetGraphicsResetStatusKHR() will
> return an error if the gles2::ShareGroup has been lost.
> 
> We remove the GpuControl::IsChannelLost() method as this is now unused.
> The CmdBufferHelper::IsContextLost() is still needed for the
> QueryTracker, so insert a comment and a TODO explaining why and how
> it could be removed.
> 
> R=piman, sievers
> BUG=584497
>
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel
> 
> Committed: https://crrev.com/b1f17d6f3f988d7b190cab1147b1e20da0647a44
> Cr-Commit-Position: refs/heads/master@{#389947}

TBR=piman@chromium.org,sievers@chromium.org,fsamuel@google.com,sky@chromium.o...
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=584497
==========

[commit-bot: I haz the power, 2016-04-27 03:33:08]

Committed patchset #1 (id:1)

[Matt Giuca, 2016-04-27 03:34:12]

Description was changed from

==========
Revert of Report lost context from GLES2Implementation based on share group
state. (patchset #3 id:40001 of https://codereview.chromium.org/1916303003/ )

Reason for revert:
Seems to be crashing tests. See two attached bugs:

1. BrowserGpuChannelHostFactoryTest crashes in GPU-related code.
DCHECK(IsContextLost(context_provider->ContextGL())) is failing in the second
stack trace, which leads me to this CL. https://crbug.com/607048.
2. virtual/gpu/fast/canvas/canvas-lost-gpu-context.html LayoutTest is failing
with "Graphics context loss did not destroy canvas contents." The mention of
context loss also leads me to this CL. https://crbug.com/607049.

Speculatively reverting.

BUG=607048,607049

Original issue's description:
> Report lost context from GLES2Implementation based on share group state.
> 
> When any context in a gles2::ShareGroup becomes lost, all contexts in
> the same group should report that they are lost immediately. This avoids
> races such as the following:
> 
> IPC thread hears of the loss of Context 1 and 2.
> IPC thread posts to thread B for Context 1.
> Context 1 hears it is lost on thread B. Posts to thread A to recreate.
> IPC thread posts to thread A for Context 2.
> Context 1 is recreated on thread A. Puts itself in same share group as 2.
> Context 2 hears it is lost on thread A, makes a new share group.
> 
> This can lead to racey cases where share groups get split apart.
> 
> Resolve this by storing a |lost_| state on gles2::ShareGroup. When
> GLES2Implementation hears of OnGpuControlLostContext, it will set the
> lost state on the ShareGroup. Now glGetGraphicsResetStatusKHR() will
> return an error if the gles2::ShareGroup has been lost.
> 
> We remove the GpuControl::IsChannelLost() method as this is now unused.
> The CmdBufferHelper::IsContextLost() is still needed for the
> QueryTracker, so insert a comment and a TODO explaining why and how
> it could be removed.
> 
> R=piman, sievers
> BUG=584497
>
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel
> 
> Committed: https://crrev.com/b1f17d6f3f988d7b190cab1147b1e20da0647a44
> Cr-Commit-Position: refs/heads/master@{#389947}

TBR=piman@chromium.org,sievers@chromium.org,fsamuel@google.com,sky@chromium.o...
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=584497
==========

to

==========
Revert of Report lost context from GLES2Implementation based on share group
state. (patchset #3 id:40001 of https://codereview.chromium.org/1916303003/ )

Reason for revert:
Seems to be crashing tests. See two attached bugs:

1. BrowserGpuChannelHostFactoryTest crashes in GPU-related code.
   DCHECK(IsContextLost(context_provider->ContextGL())) is failing in
   the second stack trace, which leads me to this CL.
   https://crbug.com/607048.
2. virtual/gpu/fast/canvas/canvas-lost-gpu-context.html LayoutTest is
   failing with "Graphics context loss did not destroy canvas contents."
   The mention of context loss also leads me to this CL.
   https://crbug.com/607049.

Speculatively reverting.

Original issue's description:
> Report lost context from GLES2Implementation based on share group state.
> 
> When any context in a gles2::ShareGroup becomes lost, all contexts in
> the same group should report that they are lost immediately. This avoids
> races such as the following:
> 
> IPC thread hears of the loss of Context 1 and 2.
> IPC thread posts to thread B for Context 1.
> Context 1 hears it is lost on thread B. Posts to thread A to recreate.
> IPC thread posts to thread A for Context 2.
> Context 1 is recreated on thread A. Puts itself in same share group as 2.
> Context 2 hears it is lost on thread A, makes a new share group.
> 
> This can lead to racey cases where share groups get split apart.
> 
> Resolve this by storing a |lost_| state on gles2::ShareGroup. When
> GLES2Implementation hears of OnGpuControlLostContext, it will set the
> lost state on the ShareGroup. Now glGetGraphicsResetStatusKHR() will
> return an error if the gles2::ShareGroup has been lost.
> 
> We remove the GpuControl::IsChannelLost() method as this is now unused.
> The CmdBufferHelper::IsContextLost() is still needed for the
> QueryTracker, so insert a comment and a TODO explaining why and how
> it could be removed.
> 
> R=piman, sievers
> BUG=584497
>
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel
> 
> Committed: https://crrev.com/b1f17d6f3f988d7b190cab1147b1e20da0647a44
> Cr-Commit-Position: refs/heads/master@{#389947}

TBR=piman@chromium.org,sievers@chromium.org,fsamuel@google.com,sky@chromium.o...
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=584497,607048,607049
==========

[commit-bot: I haz the power, 2016-04-27 03:34:25]

Description was changed from

==========
Revert of Report lost context from GLES2Implementation based on share group
state. (patchset #3 id:40001 of https://codereview.chromium.org/1916303003/ )

Reason for revert:
Seems to be crashing tests. See two attached bugs:

1. BrowserGpuChannelHostFactoryTest crashes in GPU-related code.
   DCHECK(IsContextLost(context_provider->ContextGL())) is failing in
   the second stack trace, which leads me to this CL.
   https://crbug.com/607048.
2. virtual/gpu/fast/canvas/canvas-lost-gpu-context.html LayoutTest is
   failing with "Graphics context loss did not destroy canvas contents."
   The mention of context loss also leads me to this CL.
   https://crbug.com/607049.

Speculatively reverting.

Original issue's description:
> Report lost context from GLES2Implementation based on share group state.
> 
> When any context in a gles2::ShareGroup becomes lost, all contexts in
> the same group should report that they are lost immediately. This avoids
> races such as the following:
> 
> IPC thread hears of the loss of Context 1 and 2.
> IPC thread posts to thread B for Context 1.
> Context 1 hears it is lost on thread B. Posts to thread A to recreate.
> IPC thread posts to thread A for Context 2.
> Context 1 is recreated on thread A. Puts itself in same share group as 2.
> Context 2 hears it is lost on thread A, makes a new share group.
> 
> This can lead to racey cases where share groups get split apart.
> 
> Resolve this by storing a |lost_| state on gles2::ShareGroup. When
> GLES2Implementation hears of OnGpuControlLostContext, it will set the
> lost state on the ShareGroup. Now glGetGraphicsResetStatusKHR() will
> return an error if the gles2::ShareGroup has been lost.
> 
> We remove the GpuControl::IsChannelLost() method as this is now unused.
> The CmdBufferHelper::IsContextLost() is still needed for the
> QueryTracker, so insert a comment and a TODO explaining why and how
> it could be removed.
> 
> R=piman, sievers
> BUG=584497
>
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel
> 
> Committed: https://crrev.com/b1f17d6f3f988d7b190cab1147b1e20da0647a44
> Cr-Commit-Position: refs/heads/master@{#389947}

TBR=piman@chromium.org,sievers@chromium.org,fsamuel@google.com,sky@chromium.o...
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=584497,607048,607049
==========

to

==========
Revert of Report lost context from GLES2Implementation based on share group
state. (patchset #3 id:40001 of https://codereview.chromium.org/1916303003/ )

Reason for revert:
Seems to be crashing tests. See two attached bugs:

1. BrowserGpuChannelHostFactoryTest crashes in GPU-related code.
DCHECK(IsContextLost(context_provider->ContextGL())) is failing in the second
stack trace, which leads me to this CL. https://crbug.com/607048.
2. virtual/gpu/fast/canvas/canvas-lost-gpu-context.html LayoutTest is failing
with "Graphics context loss did not destroy canvas contents." The mention of
context loss also leads me to this CL. https://crbug.com/607049.

Speculatively reverting.

BUG=607048,607049

Original issue's description:
> Report lost context from GLES2Implementation based on share group state.
>
> When any context in a gles2::ShareGroup becomes lost, all contexts in
> the same group should report that they are lost immediately. This avoids
> races such as the following:
>
> IPC thread hears of the loss of Context 1 and 2.
> IPC thread posts to thread B for Context 1.
> Context 1 hears it is lost on thread B. Posts to thread A to recreate.
> IPC thread posts to thread A for Context 2.
> Context 1 is recreated on thread A. Puts itself in same share group as 2.
> Context 2 hears it is lost on thread A, makes a new share group.
>
> This can lead to racey cases where share groups get split apart.
>
> Resolve this by storing a |lost_| state on gles2::ShareGroup. When
> GLES2Implementation hears of OnGpuControlLostContext, it will set the
> lost state on the ShareGroup. Now glGetGraphicsResetStatusKHR() will
> return an error if the gles2::ShareGroup has been lost.
>
> We remove the GpuControl::IsChannelLost() method as this is now unused.
> The CmdBufferHelper::IsContextLost() is still needed for the
> QueryTracker, so insert a comment and a TODO explaining why and how
> it could be removed.
>
> R=piman, sievers
> BUG=584497
>
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel
>
> Committed: https://crrev.com/b1f17d6f3f988d7b190cab1147b1e20da0647a44
> Cr-Commit-Position: refs/heads/master@{#389947}

TBR=piman@chromium.org,sievers@chromium.org,fsamuel@google.com,sky@chromium.o...
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=584497

Committed: https://crrev.com/2cc4cad984106eeb0309f2af08a35cad6c53a59f
Cr-Commit-Position: refs/heads/master@{#389980}
==========

[commit-bot: I haz the power, 2016-04-27 03:34:26]

Patchset 1 (id:??) landed as
https://crrev.com/2cc4cad984106eeb0309f2af08a35cad6c53a59f
Cr-Commit-Position: refs/heads/master@{#389980}