Make GLES2Implementation use a larger chunk size for mapping functions.

Make GLES2Implementation use a larger chunk size for mapping functions.

This will make it allocate less shared memory blocks resulting
in less file descriptors.

BUG=none
TEST=unit tests


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=107544

[greggman, 2011-10-26 20:18:04]

Hey Vangelis, Please review when you get a chance.

I set the default to 2meg which should be 8 compositor tiles which means 1/8th
the shared memory file descriptor.

[vangelis, 2011-10-26 21:27:32]

On 2011/10/26 20:18:04, greggman wrote:
> Hey Vangelis, Please review when you get a chance.
> 
> I set the default to 2meg which should be 8 compositor tiles which means 1/8th
> the shared memory file descriptor.

Thanks, Gregg. 

This seems like a good thing to me. Folks on the CC line, any objections from
your respective platforms?

[marcheu, 2011-10-26 23:00:27]

On 2011/10/26 21:27:32, vangelis wrote:
> On 2011/10/26 20:18:04, greggman wrote:
> > Hey Vangelis, Please review when you get a chance.
> > 
> > I set the default to 2meg which should be 8 compositor tiles which means
1/8th
> > the shared memory file descriptor.
> 
> Thanks, Gregg. 
> 
> This seems like a good thing to me. Folks on the CC line, any objections from
> your respective platforms?

Yes that's perfectly reasonable for Chrome OS.

[greggman, 2011-10-26 23:04:43]

Ok then, can I get an lgtm?

[vangelis, 2011-10-27 04:52:12]

On 2011/10/26 23:04:43, greggman wrote:
> Ok then, can I get an lgtm?

LGTM

[commit-bot: I haz the power, 2011-10-27 07:39:38]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/gman@chromium.org/8340003/2001

[commit-bot: I haz the power, 2011-10-27 08:48:57]

Change committed as 107544

[lain Merrick, 2011-10-27 15:35:43]

Does this mean we have a 2MB command buffer per renderer? Or per renderer
process?

Either way, that seems bad for memory-limited platforms. I guess we can override
the default in those cases, though.

[greggman, 2011-10-27 19:32:17]

On 2011/10/27 15:35:43, Iain Merrick wrote:
> Does this mean we have a 2MB command buffer per renderer? Or per renderer
> process?

Per command buffer, per renderer, for command buffers that use MapXXX
extensions. Pretty much any command buffer that is using the MapXXX functions is
already using well over 2meg. This just makes it allocate 2meg at a time instead
of lots of little allocations.


> 
> Either way, that seems bad for memory-limited platforms. I guess we can
override
> the default in those cases, though.

[vangelis, 2011-10-27 19:45:01]

On 2011/10/27 19:32:17, greggman wrote:
> On 2011/10/27 15:35:43, Iain Merrick wrote:
> > Does this mean we have a 2MB command buffer per renderer? Or per renderer
> > process?
> 
> Per command buffer, per renderer, for command buffers that use MapXXX
> extensions. Pretty much any command buffer that is using the MapXXX functions
is
> already using well over 2meg. This just makes it allocate 2meg at a time
instead
> of lots of little allocations.
> 
> 
> > 
> > Either way, that seems bad for memory-limited platforms. I guess we can
> override
> > the default in those cases, though.

As things currently stand, I don't believe we have any platforms where we will
be using less than 8 tiles to display the root contents.  So even after this
change you shouldn't be seeing increased mem usage, other than potential
leftovers from additional transfer buffers.  Given that a recent change Gregg
made we can now free unused SHM chunks when tabs become invisible usage won't
grow proportional to the  # of tabs.

[lain Merrick, 2011-10-28 08:48:06]

Great, thanks for clarifying! Belatedly LGTM