cc: Decrease transfer buffer memory limit to a single frame of uploads.

cc: Decrease transfer buffer memory limit to a single frame of uploads.

This memory limit is a lowest-common-denominator type value that should
work for more-or-less all platforms. Currently this value causes
impl-side painting to increase the size of the renderer process resident
memory, which is causing memory regressions on the perf bots.

But, having enough memory for 2 frames seems excessive as the baseline
since in the common case we need to upload resources for the next
compositor deadline that will be presented at the next vsync. So, remove
the 2x multiplier from this constant value.

R=reveman
BUG=407193
Committed: https://crrev.com/e6a236bc7aa96ba49a121f9c057d93bfc28cd235
Cr-Commit-Position: refs/heads/master@{#293001}

[danakj, 2014-08-30 00:29:00]

https://codereview.chromium.org/522023002/diff/1/cc/trees/layer_tree_host_imp...
File cc/trees/layer_tree_host_impl.cc (left):

https://codereview.chromium.org/522023002/diff/1/cc/trees/layer_tree_host_imp...
cc/trees/layer_tree_host_impl.cc:2069: transfer_buffer_memory_limit_ =
this is also set in CreateAndSetTileManager() which is called next.

[reveman, 2014-08-30 00:38:39]

lgtm with a few nits

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

https://codereview.chromium.org/522023002/diff/1/cc/trees/layer_tree_host_imp...
cc/trees/layer_tree_host_impl.cc:106: // the next frame deadline.
maybe worth mentioning that this assumes no more than a one frame deep pipeline
between CPU and GPU. and if we have more than that it might cause us to issue
less uploads than we can perform.

https://codereview.chromium.org/522023002/diff/1/cc/trees/layer_tree_host_imp...
cc/trees/layer_tree_host_impl.cc:109: ms_per_frame * kMaxBytesUploadedPerMs;
nit: up to you but I'd get rid of the 'const' modifier here

https://codereview.chromium.org/522023002/diff/1/cc/trees/layer_tree_host_imp...
cc/trees/layer_tree_host_impl.cc:111: // The context may request a higher limit
based on the device capabilities.
nit: lower limit based on the device capabilities.

[danakj, 2014-08-30 00:42:32]

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

https://codereview.chromium.org/522023002/diff/1/cc/trees/layer_tree_host_imp...
cc/trees/layer_tree_host_impl.cc:109: ms_per_frame * kMaxBytesUploadedPerMs;
On 2014/08/30 00:38:39, reveman wrote:
> nit: up to you but I'd get rid of the 'const' modifier here

Done.

https://codereview.chromium.org/522023002/diff/1/cc/trees/layer_tree_host_imp...
cc/trees/layer_tree_host_impl.cc:111: // The context may request a higher limit
based on the device capabilities.
On 2014/08/30 00:38:39, reveman wrote:
> nit: lower limit based on the device capabilities.

I would have to change std::min to std::max then. Right now it can only increase
the number. Maybe this points to a bug, I will file one.

[danakj, 2014-08-30 00:44:28]

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

https://codereview.chromium.org/522023002/diff/1/cc/trees/layer_tree_host_imp...
cc/trees/layer_tree_host_impl.cc:111: // The context may request a higher limit
based on the device capabilities.
On 2014/08/30 00:42:32, danakj wrote:
> On 2014/08/30 00:38:39, reveman wrote:
> > nit: lower limit based on the device capabilities.
> 
> I would have to change std::min to std::max then. Right now it can only
increase
> the number. Maybe this points to a bug, I will file one.

Oh, no I agree with you. Fridays~

[danakj, 2014-08-30 00:51:38]

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

https://codereview.chromium.org/522023002/diff/1/cc/trees/layer_tree_host_imp...
cc/trees/layer_tree_host_impl.cc:106: // the next frame deadline.
On 2014/08/30 00:38:39, reveman wrote:
> maybe worth mentioning that this assumes no more than a one frame deep
pipeline
> between CPU and GPU. and if we have more than that it might cause us to issue
> less uploads than we can perform.  

I added something, let me know if you think it's a lie :)

[reveman, 2014-08-30 02:00:56]

https://codereview.chromium.org/522023002/diff/40001/cc/trees/layer_tree_host...
File cc/trees/layer_tree_host_impl.cc (right):

https://codereview.chromium.org/522023002/diff/40001/cc/trees/layer_tree_host...
cc/trees/layer_tree_host_impl.cc:110: // browser, so there's no benefit to
starting it early.
I don't understand how frame deadlines would effect this.

[danakj, 2014-09-02 20:07:46]

The CQ bit was checked by danakj@chromium.org

[danakj, 2014-09-02 20:08:21]

Ok I fixed up the comment to talk about latency til the GPU process picks up new
upload requests from the compositor. Thanks for your super patient explanation
until I got what you meant :)

[commit-bot: I haz the power, 2014-09-02 20:08:49]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/danakj@chromium.org/522023002/60001

[commit-bot: I haz the power, 2014-09-02 21:43:23]

Committed patchset #4 (id:60001) as 8050665546f1f97d494e3dde6b4d13f054f36d00

[commit-bot: I haz the power, 2014-09-10 03:20:58]

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