Gpu memory not freed Instantly

[santosh mahto]

Hi all

We are facing an issue(embeded low end device gpu:128mb) in which gpu memory is not freed intsantly but later some point of time. if we keep allocating fastly the memory consumption cross limit because old one is not freed. 

When I checked with window chrome browser(Google Chrome40.0.2214.115) I found same issue. On allocation gpu memory goes high but on deallocation/refresh the gpu memory doesn't decrease. Memory get freed once we close the tab and open the tab.

see the images:

snapshot on page load.

gpu_initial.png

snapshot after allocating 

gpu_hingh.png.

snapshot after refreshing the page(back to original)

gpu_afterrefresh.png.

I would like to why this behavior ? or if it is a bug.

[Vangelis Kokkevis]

Over the past few years, we've wrestled with GPU memory management quite a bit. In the end we realized that a simple memory policy works best for most cases. The situation we have today is that the renderers are given a (rather high) budget to use for tile textures. While tile textures do get recycled, as long as we're under the budget no attempt is made to free textures that are no longer in use. The reasoning goes that if the page at some point needed these resources to draw, there's a good chance that it will do so again and we don't want to incur frequent allocation and de-allocation overheads. When a tab is backgrounded or closed, textures will be freed, as you've noticed.

This could in theory be a problem if there are lots of concurrently open browser windows that all had high memory needs at some point. On the other hand, at least on Windows, our experience has been that the drivers do a reasonably good job at paging graphics memory based on use so high allocations don't appear to be an issue.  It's also less of a problem on Android where there's only one tab active at a time.

Vangelis

To unsubscribe from this group and stop receiving emails from it, send an email to graphics-dev...@chromium.org.

[sam...@cisco.com]

Hi

Thanks for information.
We have embedded platform(STB) with only one browser window which frequently loads and displays new images and removing old images.The window can't be backgrounded or closed. In common case gpu memory increases but also decreases after few timestamps maintaining limited gpu memory usage. But when allocation keep happening too fast and continuously gpu memory keep increasing crossing max limit. I guess in this case recycling doesn't happen because it doesn't get idle time due to continuous allocation.

So does recycling is triggered before allocation when it is close to max limit or it is done when gpu process is not busy?
and Could you explain more about recycling policy(pointing to code). I mean when it is triggered.Is there way to enforce it(any hooks)?

[Justin Novosad]

Tip: If you are using 2D canvases, set their size to zero before discarding canvases in order to free their GPU memory (if any) immediately. Otherwise the element may continue to consume GPU memory until it is garbage collected.

[Arunprasad]

On Friday, 27 February 2015 23:01:17 UTC+5:30, vangelis wrote:
> Over the past few years, we've wrestled with GPU memory management quite a bit. In the end we realized that a simple memory policy works best for most cases. The situation we have today is that the renderers are given a (rather high) budget to use for tile textures. While tile textures do get recycled, as long as we're under the budget no attempt is made to free textures that are no longer in use. The reasoning goes that if the page at some point needed these resources to draw, there's a good chance that it will do so again and we don't want to incur frequent allocation and de-allocation overheads. When a tab is backgrounded or closed, textures will be freed, as you've noticed.

​This policy is perfect for tiled backing store's textures(since it's size is constant),​ ​but I'm wondering why layer's textures are also ​not freed.