cc: Add command line switch to control resource usage for impl-side painting.

cc/resources/resource_pool.cc

 // Copyright 2012 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/resource_pool.h"
 
 #include "cc/resources/resource_provider.h"
 
 namespace cc {
 
@@ skipping 12 matching lines @@
 
 ResourcePool::Resource::~Resource() {
   DCHECK(id());
   DCHECK(resource_provider_);
   resource_provider_->DeleteResource(id());
 }
 
 ResourcePool::ResourcePool(ResourceProvider* resource_provider)
     : resource_provider_(resource_provider),
       max_memory_usage_bytes_(0),
-      memory_usage_bytes_(0) {
+      memory_usage_bytes_(0),
+      acquired_memory_usage_bytes_(0) {
 }
 
 ResourcePool::~ResourcePool() {
   SetMaxMemoryUsageBytes(0);
 }
 
 scoped_ptr<ResourcePool::Resource> ResourcePool::AcquireResource(
     const gfx::Size& size, GLenum format) {
   for (ResourceList::iterator it = resources_.begin();
        it != resources_.end(); ++it) {
     Resource* resource = *it;
 
     // TODO(epenner): It would be nice to DCHECK that this
     // doesn't happen two frames in a row for any resource
     // in this pool.
     if (!resource_provider_->CanLockForWrite(resource->id()))
       continue;
 
     if (resource->size() != size)
       continue;
     if (resource->format() != format)
       continue;
 
     resources_.erase(it);
+    acquired_memory_usage_bytes_ += resource->bytes();
     return make_scoped_ptr(resource);
   }
 
   // Create new resource.
   Resource* resource = new Resource(
       resource_provider_, size, format);
 
   // Extend all read locks on all resources until the resource is
   // finished being used, such that we know when resources are
   // truly safe to recycle.
   resource_provider_->EnableReadLockFences(resource->id(), true);
 
   memory_usage_bytes_ += resource->bytes();
+  acquired_memory_usage_bytes_ += resource->bytes();
   return make_scoped_ptr(resource);
 }
 
 void ResourcePool::ReleaseResource(
     scoped_ptr<ResourcePool::Resource> resource) {
+  acquired_memory_usage_bytes_ -= resource->bytes();
   if (memory_usage_bytes_ > max_memory_usage_bytes_) {
     memory_usage_bytes_ -= resource->bytes();
     return;
   }
 
   resources_.push_back(resource.release());
 }
 
 void ResourcePool::SetMaxMemoryUsageBytes(size_t max_memory_usage_bytes) {
   max_memory_usage_bytes_ = max_memory_usage_bytes;
 
   while (!resources_.empty()) {
     if (memory_usage_bytes_ <= max_memory_usage_bytes_)
       break;
-    Resource* resource = resources_.front();
-    resources_.pop_front();
-    memory_usage_bytes_ -= resource->bytes();
-    delete resource;
+
+    EvictOneResource();
   }
 }
 
+void ResourcePool::ReduceMemoryUsage() {
+  size_t ten_percent_of_memory = max_memory_usage_bytes_ / 10;

[piman, 2013/03/25 18:13:46]

What would happen if we didn't try to keep anything?
10% of 1GB (the current limit on Chrome OS) is 100MB. I want to make sure 100MB
allocated per visible tab is worth whatever we hope to save in perf.

[reveman, 2013/03/25 18:36:06]

we have to pay the cost of allocating texture, pixel-transfer-buffer and query
more frequently. so basically some shallow flushes and whatever driver side cost
we have for creating a new texture. this might not be too bad on chromeos but
excessive amounts of cache misses for each pending tree activation will
undoubtedly have a performance impact.

I picked 10% as that's what we use in the old texture manager. I don't have any
data showing that this is the right number. I've only done some minimal testing
and not seen a significant perf impact.

[nduca, 2013/03/25 18:37:49]

How does this compare to a "please drop everything" policy? I'm really leery of
a memory managment strategy that drops some but not everything.

If you see a difference between the two, can we use the
allow_nothing/minimum/prepaint/anything policy instead? And ideally tie them
together more closely?

[reveman, 2013/03/25 18:47:33]

if we drop everything then initializing a new pending tree will be more costly
as we'll have to create new resources for every single tile. it might affect
active tree performance a bit too with the current read lock fences as we can't
reuse textures that we recently used for drawing.
sg, I forgot that we had that.

+  while (!resources_.empty()) {
+    size_t wasted_usage_bytes =
+        memory_usage_bytes_ - acquired_memory_usage_bytes_;
+    if (wasted_usage_bytes <= ten_percent_of_memory)
+      break;
+
+    EvictOneResource();
+  }
+}
+
+void ResourcePool::EvictOneResource() {
+  DCHECK(!resources_.empty());
+  // MRU eviction pattern as least recently used is less likely to
+  // be blocked by read lock fence.
+  Resource* resource = resources_.back();
+  resources_.pop_back();
+  memory_usage_bytes_ -= resource->bytes();
+  delete resource;
+}
+
 }  // namespace cc