Re: Issue 126528 in chromium: GpuMemoryManager should accept memory allocation hints from renderers to help distribute memory fairly.

6 views
Skip to first unread message

chro...@googlecode.com

unread,
May 11, 2012, 1:29:00 PM5/11/12
to chromi...@chromium.org
Updates:
Labels: Mstone-21

Comment #1 on issue 126528 by mmo...@chromium.org: GpuMemoryManager should
accept memory allocation hints from renderers to help distribute memory
fairly.
http://code.google.com/p/chromium/issues/detail?id=126528

(No comment was entered for this change.)

chro...@googlecode.com

unread,
May 25, 2012, 10:38:14 AM5/25/12
to chromi...@chromium.org

Comment #2 on issue 126528 by g...@chromium.org: GpuMemoryManager should
accept memory allocation hints from renderers to help distribute memory
fairly.
http://code.google.com/p/chromium/issues/detail?id=126528

What is the GpuMemoryManager and how is it tracking VRAM? It's VRAM we
need tracked, not RAM.

chro...@googlecode.com

unread,
May 25, 2012, 11:26:41 AM5/25/12
to chromi...@chromium.org

Comment #3 on issue 126528 by mmo...@chromium.org: GpuMemoryManager should
accept memory allocation hints from renderers to help distribute memory
fairly.
http://code.google.com/p/chromium/issues/detail?id=126528

RE What is the GpuMemoryManager: This is an older document Nat and I put
together and sent out to chrome-gpu, though its likely a little stale:
https://docs.google.com/a/google.com/document/d/14a8cxadDOd5984peJwTjvb2oT6xElpETrQxhOmBoCsY/edit?hl=en_US

Short summary of current state:
* It tracks tab visibility and last_use_time
* manages various graphics contexts accordingly, by:
* * splitting the memory cap across the renderer/browser compositors of
visible tabs
* * background tabs are told to purge all memory
* * also sends a message to accelerated canvas shared graphics context to
purge its memory when all tabs in that render process are backgrounded and
fall off some LRU threshold.


Currently it does not:
* Tack WebGL whatsoever
* Query system vram availability: assumes 448M -- chosen because that would
have previously been the *potential* usage at 3 open windows
* Receive memory usage hints from compositors so it can split memory
unevenly
* Do many other nice things

chro...@googlecode.com

unread,
Jun 1, 2012, 4:27:42 PM6/1/12
to chromi...@chromium.org
Updates:
Status: Started

Comment #4 on issue 126528 by mmo...@chromium.org: GpuMemoryManager should
accept memory allocation hints from renderers to help distribute memory
fairly.
http://code.google.com/p/chromium/issues/detail?id=126528

chro...@googlecode.com

unread,
Jun 7, 2012, 4:48:04 PM6/7/12
to chromi...@chromium.org
Updates:
Labels: -Mstone-21 Mstone-22

Comment #5 on issue 126528 by mmo...@chromium.org: GpuMemoryManager should
accept memory allocation hints from renderers to help distribute memory
fairly.
http://code.google.com/p/chromium/issues/detail?id=126528

Bumping to M22. It is more important to track actual memory usage of
various clients and drop contexts etc when memory availability is tight,
than it is to worry about giving better ideal allocations for prepainting
in the compositor.

Additionally, the direction of the current texture managers is that they
will just use all the memory they are given, and until we calculate current
figures for (min, ideal) allocations, there is no sense sending current
memory usage numbers.

Reply all
Reply to author
Forward
0 new messages