GPU process clients can perform a "shallow" finish.

The semantics of shallow finish are to block until the GPU process has issued all prior GL commands, without necessarily waiting for the GPU to complete them. It might have better performance than a regular finish in some cases. It is also less likely to hang if the GPU hangs on some platforms, such as Windows.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=207985

[apatrick_chromium, 2013-06-21 00:15:04]

Patch set #1 is interesting too. I commented out all the Finish usage in cc
until I got chrome to compile. There are three places that call Finish(). I
wonder if they could be ShallowFinish()?

[piman, 2013-06-21 00:48:55]

On 2013/06/21 00:15:04, apatrick_chromium wrote:
> Patch set #1 is interesting too. I commented out all the Finish usage in cc
> until I got chrome to compile. There are three places that call Finish(). I
> wonder if they could be ShallowFinish()?

PS#3 LGTM. See comments I left in PS#1, I think we can change at least some of
them to shallow finish.

[piman, 2013-06-21 02:31:10]

https://codereview.chromium.org/17504006/diff/1/cc/output/gl_renderer.cc
File cc/output/gl_renderer.cc (right):

https://codereview.chromium.org/17504006/diff/1/cc/output/gl_renderer.cc#newc...
cc/output/gl_renderer.cc:2346: // Can this be a flush?
It can't because we're waiting on the the ReadPixels to be done on the GPU
process side (it's async when GL_PIXEL_PACK_TRANSFER_BUFFER_CHROMIUM != 0).
In the current version, it can be made a shallow flush.

In the future though, we want to have an async readpixels on the GPU process
side (using PBOs), which will need a sort of finish to complete synchronously,
or something.

https://codereview.chromium.org/17504006/diff/1/cc/trees/layer_tree_host_impl.cc
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/17504006/diff/1/cc/trees/layer_tree_host_impl...
cc/trees/layer_tree_host_impl.cc:1222: // Can this be a flush?
I believe this was needed at some point on some platforms (was it mac?) to avoid
flashing when switching from composited to non-composited.
Mac switched to --force-compositing-mode, so it may not be needed any more.

https://codereview.chromium.org/17504006/diff/1/cc/trees/thread_proxy.cc
File cc/trees/thread_proxy.cc (right):

https://codereview.chromium.org/17504006/diff/1/cc/trees/thread_proxy.cc#newc...
cc/trees/thread_proxy.cc:1218: // Can this be a flush?
I think this can be a shallow finish. The idea here is to ensure the
asynchronous readpixels have a chance to complete. See caveat in gl_renderer
though.

[commit-bot: I haz the power, 2013-06-21 18:19:46]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/apatrick@chromium.org/17504006/29001

[commit-bot: I haz the power, 2013-06-22 00:59:38]

Change committed as 207985