[chromium-dev] about memory usage of gpu-process

[Simon Hong]

Hi,

When I run chromium (build with chromeos=1), GPU memory of Browser process is 12,863k (with only task-manager, no browser window).

After open with google.com, gpu memory of browser process is almost 33,000k.

After I closed browser window. browser process's gpu memory is still 33,000k. It is not reduced by closing browser window.

But, when I delete gpu-process by using end process button of task-manager, it is back to 12.800k.

I don't know much about gpu memory of gpu-procss or browser process.

Is this a normal situation?

If anyone knows why this is happened, please explain.

Thank you.

Simon.

[Christopher Cameron]

To be clear, this is the GPU memory usage, not the system memory usage, correct?

Do you see any GPU memory usage for the renderer processes (and does it go away)?

If indeed this the jump from 12M->33M is because of the browser (perhaps Aura), then it's probably the case that this is the texture manager keeping around recently-deleted textures "just in case" they are needed in the future.  This is critical for performance on some platforms (Android), but less helpful on some desktop platforms (and perhaps it should be disabled).

If you want to verify that this is due to recycling, modify cc/prioritized_texture_manager.cc "size_t tenPercentOfMemory = m_memoryAvailableBytes / 10;" to just be "0", and see if that sorts out the issue.

epenner, gman, and I are discussing ways to simplify this recycling situation.

C

Simon.

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Simon Hong]

On Tue, Nov 13, 2012 at 5:26 AM, Christopher Cameron <ccam...@chromium.org> wrote:

To be clear, this is the GPU memory usage, not the system memory usage, correct?

 

Yes , GPU memory value that task manager shows.

Do you see any GPU memory usage for the renderer processes (and does it go away)?

 

When I visit, chrome webapp store, it uses almost 50MB for gpu memory (only in renderer)

Also browser process's gpu memory is increased about 10MB.

When I close that tab, renderer's gpu memory is dissapeared but browser process's gpu memory is not backed to previous.

If indeed this the jump from 12M->33M is because of the browser (perhaps Aura), then it's probably the case that this is the texture manager keeping around recently-deleted textures "just in case" they are needed in the future.  This is critical for performance on 

some platforms (Android), but less helpful on some desktop platforms (and perhaps it should be disabled).

 

Yes, I didn't notice any slow execution.

If you want to verify that this is due to recycling, modify cc/prioritized_texture_manager.cc "size_t tenPercentOfMemory = m_memoryAvailableBytes / 10;" to just be "0", and see if that sorts out the issue.

With this modification,  gpu memory is backed to previous exactly (almost 9MB, no browser window only task manager).

I have a question about when reduceMemory() is called?

when closing a tab?

Thank you!

[Christopher Cameron]

Thanks for running this experiment!  

On Mon, Nov 12, 2012 at 1:57 PM, Simon Hong <simon....@gmail.com> wrote:

Yes, I didn't notice any slow execution.

If you want to verify that this is due to recycling, modify cc/prioritized_texture_manager.cc "size_t tenPercentOfMemory = m_memoryAvailableBytes / 10;" to just be "0", and see if that sorts out the issue.

With this modification,  gpu memory is backed to previous exactly (almost 9MB, no browser window only task manager).

That 9MB is what's used by Aura to draw the task manager window and its contents.

 

I have a question about when reduceMemory() is called?

when closing a tab?

reduceMemory is called every time a new frame is committed, to free up any resources that are no longer needed.

For the moment, the behavior that you're seeing is indeed expected.  It's fairly likely that around M25 or M26 (or earlier), we'll have a better scheme for recycling textures, and we'll no longer use this extra memory.  I'll also look into disabling texture recycling on the desktop platforms where it doesn't help.

C

[Simon Hong]

2012. 11. 13. 오전 7:13에 "Christopher Cameron" <ccam...@chromium.org>님이 작성:

Great!! That's what I really want :)
Thank you!!
>
> C

[Stéphane Marchesin]

Tangentially related: is there a way (or could we get a way) to flush out all the "just in case" textures for the sake of finding memory leaks? Otherwise finding leaks becomes hairy (especially if you're leaking a few 100s of Kb)

We could also use such a feature for the Chrome OS memory tests, where we do things like open 10 tabs and measure memory use before/during/after. Right now any small leak is lost in the noise, it'd be great to be able to tell Chrome to flush everything out.

Stéphane

[Christopher Cameron]

Yes, there are a few ways it can be cleared out -- how exactly to do it depends on where you want to send the signal from (probably the most straightforward is to change that "10%" constant in the texture manager if a flag is set).

C

[Stéphane Marchesin]

Is there a way to automate and use this on stock builds? That would be immensely useful.

Stéphane