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

cc/resources/gpu_rasterizer.cc

 // Copyright 2015 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "cc/resources/gpu_rasterizer.h"
 
 #include <algorithm>
 
 #include "base/bind.h"
 #include "base/metrics/histogram.h"
@@ skipping 173 matching lines @@
   canvas->save();
   tile->raster_source()->PlaybackToCanvas(canvas.get(), tile->content_rect(),
                                           tile->contents_scale());
   canvas->restore();
 
   // Add the canvas and recorded picture to |multi_picture_draw_|.
   skia::RefPtr<SkPicture> picture = skia::AdoptRef(recorder.endRecording());
   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