cc: Free gpu resources when we are invisible or TM is oom.

cc/resources/gpu_rasterizer.cc

Index: cc/resources/gpu_rasterizer.cc
diff --git a/cc/resources/gpu_rasterizer.cc b/cc/resources/gpu_rasterizer.cc
index 6e318edabbe80a2c670eef3baf96abf9dd36d990..ff5b584aed48bd7e6036ad6aee8444e0c7e1bca9 100644
--- a/cc/resources/gpu_rasterizer.cc
+++ b/cc/resources/gpu_rasterizer.cc
@@ -191,4 +191,27 @@ void GpuRasterizer::AddToMultiPictureDraw(const Tile* tile,
   multi_picture_draw_.add(sk_surface->getCanvas(), picture.get());
 }
 
+void GpuRasterizer::ClearCache() {
+  ContextProvider* context_provider =
+      resource_provider()->output_surface()->worker_context_provider();
+
+  // The context lock must be held while accessing the context on a
+  // worker thread.
+  base::AutoLock context_lock(*context_provider->GetLock());
+
+  // Allow context to bind to current thread.
+  context_provider->DetachFromThread();
+
+  // Clear resource cache.
+  GrContext* gr_context = context_provider->GrContext();
+  DCHECK(gr_context);
+  gr_context->setResourceCacheLimits(0, 0);

[vmiura, 2015/03/23 20:34:40]

We'll want to not have limits stuck at 0 forever.

Maybe restore the prior limits returned by getResourceCacheLimits after?

[sohanjg, 2015/03/24 05:42:09]

Acknowledged.
Also, should we maintain the limits as gpu_rasterizer member?
and restore them when hard_memory_limit_in_bytes is no longer zero in LTHI
global_tile_state_?

[vmiura, 2015/03/24 06:32:52]

Sounds like a good solution.

[sohanjg, 2015/03/24 13:03:36]

Done.

+
+  // Barrier to sync worker context output to cc context.
+  context_provider->ContextGL()->OrderingBarrierCHROMIUM();

[vmiura, 2015/03/23 20:34:40]

I think it's not necessary to use an ordering barrier here.

[sohanjg, 2015/03/24 05:42:09]

Acknowledged.

And i wonder, ClearCache() will be invoked from
LTHI::UpdateTileManagerMemoryPolicy(), will it really be in worker thread
context unlike RasterBufferImpl::Playback() ?

[vmiura, 2015/03/24 06:32:52]

Ah, we have to be careful here.

Threaded-GPU mode uses 'worker_context_provider', but sync-GPU uses
'context_provider'.  The latter will be removed, but for now we shouldn't break
it.

For rasterization, that's just picked here:
https://code.google.com/p/chromium/codesearch#chromium/src/cc/resources/resou...

In case it's threaded-GPU, both the worker thread and this function on the CC
thread will contend for 'worker_context_provider', hence needing the lock on
context_provider->GetLock(), context_provider->DetachFromThread(), etc.

For 'context_provider' case there is no contention.

[sohanjg, 2015/03/24 13:03:36]

Acknowledged.

+
+  // Allow context to bind to other threads.
+  context_provider->DetachFromThread();
+}
+
 }  // namespace cc