content: [Android] divide the mapped_memory_reclaim_limit for Android low-end devices by 2 since we…

content: [Android] divide the mapped_memory_reclaim_limit for Android low-end devices by 2 since we'll be using 16bpp textures instead of 32bpp

BUG=

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

[no sievers, 2013-09-19 18:37:30]

+eric, reveman.

I'm not sure this is right. This is calculated as the upload bandwidth.
Whether you are using 16bit or 32bit textures has nothing to do with it, right?

[no sievers, 2013-09-19 18:40:26]

On 2013/09/19 18:37:30, sievers wrote:
> +eric, reveman.
> 
> I'm not sure this is right. This is calculated as the upload bandwidth.
> Whether you are using 16bit or 32bit textures has nothing to do with it,
right?

Is there maybe a good place where we can cut our memory budget in half based on
'using 16 bit textures'?

[kaanb, 2013-09-19 18:50:10]

On 2013/09/19 18:40:26, sievers wrote:
> On 2013/09/19 18:37:30, sievers wrote:
> > +eric, reveman.
> > 
> > I'm not sure this is right. This is calculated as the upload bandwidth.
> > Whether you are using 16bit or 32bit textures has nothing to do with it,
> right?
> 
> Is there maybe a good place where we can cut our memory budget in half based
on
> 'using 16 bit textures'?

We've already cut it half in gl_context_android.cc conditional on low-end
devices.

[no sievers, 2013-09-19 19:10:03]

On 2013/09/19 18:50:10, kaanb wrote:
> On 2013/09/19 18:40:26, sievers wrote:
> > On 2013/09/19 18:37:30, sievers wrote:
> > > +eric, reveman.
> > > 
> > > I'm not sure this is right. This is calculated as the upload bandwidth.
> > > Whether you are using 16bit or 32bit textures has nothing to do with it,
> > right?
> > 
> > Is there maybe a good place where we can cut our memory budget in half based
> on
> > 'using 16 bit textures'?
> 
> We've already cut it half in gl_context_android.cc conditional on low-end
> devices.

Yea not sure. Admittedly the existing divider by 3 is already somewhat of a
guess, but I did actually look at some memory bandwidth numbers of devices to
come up with it :)

All the different knobs we have are supposed to mean something. I think this one
is originally intended to keep us from queuing more uploads than can be handled
(bandwidth-wise). Now you want to throttle this further to reduce the shared
memory footprint (regardless of bandwidth)- so maybe that's reasonable and the
only existing place to do it.

Fine with me either way, if the owners are happy. But I'd at least put a
comment.

Also, the hardcoded Android settings all over the place and for the different
modes (low-end vs. not and WebView, different vendors, different resolutions and
tiles size etc.) are getting less and less maintainable. You are further
hardcoding the assumptions that 16bit tiles are in use into this logic now. It
seems to be hard to get to LayerTreeSettings here to check if we are actually
using 16bit, but can you at least check
!cmd->HasSwitch(cc::switches::kDisable4444Textures()?

[reveman, 2013-09-19 19:50:42]

I don't think we should make texture format assumptions here. Checking
--disable-rgba444 here is pretty nasty too. If we want this limit to always be
less for low end devices independent of texture format then fine. If not, then
maybe this limit should be defined as texture area rather then bytes somehow.

[kaanb, 2013-09-19 20:01:35]

On 2013/09/19 19:10:03, sievers wrote:
> On 2013/09/19 18:50:10, kaanb wrote:
> > On 2013/09/19 18:40:26, sievers wrote:
> > > On 2013/09/19 18:37:30, sievers wrote:
> > > > +eric, reveman.
> > > > 
> > > > I'm not sure this is right. This is calculated as the upload bandwidth.
> > > > Whether you are using 16bit or 32bit textures has nothing to do with it,
> > > right?
> > > 
> > > Is there maybe a good place where we can cut our memory budget in half
based
> > on
> > > 'using 16 bit textures'?
> > 
> > We've already cut it half in gl_context_android.cc conditional on low-end
> > devices.
> 
> Yea not sure. Admittedly the existing divider by 3 is already somewhat of a
> guess, but I did actually look at some memory bandwidth numbers of devices to
> come up with it :)
> 
> All the different knobs we have are supposed to mean something. I think this
one
> is originally intended to keep us from queuing more uploads than can be
handled
> (bandwidth-wise). Now you want to throttle this further to reduce the shared
> memory footprint (regardless of bandwidth)- so maybe that's reasonable and the
> only existing place to do it.
> 
> Fine with me either way, if the owners are happy. But I'd at least put a
> comment.
> 
> Also, the hardcoded Android settings all over the place and for the different
> modes (low-end vs. not and WebView, different vendors, different resolutions
and
> tiles size etc.) are getting less and less maintainable. You are further
> hardcoding the assumptions that 16bit tiles are in use into this logic now. It
> seems to be hard to get to LayerTreeSettings here to check if we are actually
> using 16bit, but can you at least check
> !cmd->HasSwitch(cc::switches::kDisable4444Textures()?

I agree we have too many knobs and we have crbug.com/288188 to clean up some of
Android specific code from here. 

However in the short term we need to control the shared memory usage and this is
the only way I can think of.

[kaanb, 2013-09-19 20:01:51]

On 2013/09/19 19:50:42, David Reveman wrote:
> I don't think we should make texture format assumptions here. Checking
> --disable-rgba444 here is pretty nasty too. If we want this limit to always be
> less for low end devices independent of texture format then fine. If not, then
> maybe this limit should be defined as texture area rather then bytes somehow.

Okay, then I'll leave the patch as is.

[no sievers, 2013-09-19 20:07:01]

On 2013/09/19 20:01:51, kaanb wrote:
> On 2013/09/19 19:50:42, David Reveman wrote:
> > I don't think we should make texture format assumptions here. Checking
> > --disable-rgba444 here is pretty nasty too. If we want this limit to always
be
> > less for low end devices independent of texture format then fine. If not,
then
> > maybe this limit should be defined as texture area rather then bytes
somehow.
> 
> Okay, then I'll leave the patch as is.

lgtm

[kaanb, 2013-09-19 23:02:55]

Fixed a subtle bug that was causing the calculation to overflow. PTAL


On Thu, Sep 19, 2013 at 1:07 PM, <[email protected]> wrote:

> On 2013/09/19 20:01:51, kaanb wrote:
>
>> On 2013/09/19 19:50:42, David Reveman wrote:
>> > I don't think we should make texture format assumptions here. Checking
>> > --disable-rgba444 here is pretty nasty too. If we want this limit to
>> always
>>
> be
>
>> > less for low end devices independent of texture format then fine. If
>> not,
>>
> then
>
>> > maybe this limit should be defined as texture area rather then bytes
>>
> somehow.
>
>  Okay, then I'll leave the patch as is.
>>
>
> lgtm
>
>
https://codereview.chromium.**org/24248004/<https://codereview.chromium.org/2...
>

To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].

[jamesr, 2013-09-20 00:20:25]

this code would be simpler and less overflow-prone if you used the right units

lgtm although I'd appreciate if you'd do that too

https://codereview.chromium.org/24248004/diff/16001/content/renderer/render_w...
File content/renderer/render_widget.cc (right):

https://codereview.chromium.org/24248004/diff/16001/content/renderer/render_w...
content/renderer/render_widget.cc:2556: const size_t kMegabytes = 1024 * 1024;
static if you want this to be a real compile-time constant

https://codereview.chromium.org/24248004/diff/16001/content/renderer/render_w...
content/renderer/render_widget.cc:2566: (max_transfer_buffer_usage_bytes /
kMegabytes) * kMegabytes;
hmm, we have code elsewhere to do this (such as in cc/base/util.h) in a safer
way. would be good to generalize.

if this is supposed to be a multiple of 1MB, why isn't the unit just megabytes?

[kaanb, 2013-09-20 00:49:24]

https://codereview.chromium.org/24248004/diff/16001/content/renderer/render_w...
File content/renderer/render_widget.cc (right):

https://codereview.chromium.org/24248004/diff/16001/content/renderer/render_w...
content/renderer/render_widget.cc:2556: const size_t kMegabytes = 1024 * 1024;
On 2013/09/20 00:20:26, jamesr wrote:
> static if you want this to be a real compile-time constant

Done.

https://codereview.chromium.org/24248004/diff/16001/content/renderer/render_w...
content/renderer/render_widget.cc:2566: (max_transfer_buffer_usage_bytes /
kMegabytes) * kMegabytes;
On 2013/09/20 00:20:26, jamesr wrote:
> hmm, we have code elsewhere to do this (such as in cc/base/util.h) in a safer
> way. would be good to generalize.
> 
> if this is supposed to be a multiple of 1MB, why isn't the unit just
megabytes?

Done.

[jamesr, 2013-09-20 00:51:34]

https://codereview.chromium.org/24248004/diff/20001/content/renderer/render_w...
File content/renderer/render_widget.cc (right):

https://codereview.chromium.org/24248004/diff/20001/content/renderer/render_w...
content/renderer/render_widget.cc:2562: 2 * kMillisecondsPerFrame *
max_mb_uploaded_per_ms;
please make the double->size_t conversion explicit. this will truncate down,
right? is that what you want? the old code rounded up to the nearest MB, i
believe

[kaanb, 2013-09-20 01:01:44]

https://codereview.chromium.org/24248004/diff/20001/content/renderer/render_w...
File content/renderer/render_widget.cc (right):

https://codereview.chromium.org/24248004/diff/20001/content/renderer/render_w...
content/renderer/render_widget.cc:2562: 2 * kMillisecondsPerFrame *
max_mb_uploaded_per_ms;
On 2013/09/20 00:51:35, jamesr wrote:
> please make the double->size_t conversion explicit. this will truncate down,
> right? is that what you want? the old code rounded up to the nearest MB, i
> believe

Done.

[jamesr, 2013-09-20 01:01:47]

lgtm, thanks

[commit-bot: I haz the power, 2013-09-20 01:06:01]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/24248004/31001

[commit-bot: I haz the power, 2013-09-20 08:50:10]

Change committed as 224338