gpu: Reuse transfer buffers more aggresively

gpu/command_buffer/service/async_pixel_transfer_manager.h

Index: gpu/command_buffer/service/async_pixel_transfer_manager.h
diff --git a/gpu/command_buffer/service/async_pixel_transfer_manager.h b/gpu/command_buffer/service/async_pixel_transfer_manager.h
index d0ea5da153c4cf08cdd292d278702c70732949f2..a10b6ac69547231ee5e2063b84f5d1e093a636fa 100644
--- a/gpu/command_buffer/service/async_pixel_transfer_manager.h
+++ b/gpu/command_buffer/service/async_pixel_transfer_manager.h
@@ -62,6 +62,10 @@ class GPU_EXPORT AsyncPixelTransferManager
 
   virtual void BindCompletedAsyncTransfers() = 0;
 
+  // Run the given callback when all already queued tasks has been processed.
+  // This includes asynchronous upload tasks.

[piman, 2014/02/07 22:58:20]

I'm not the biggest fan of this pattern, because it's very hard to reason with.
It's not inconceivable that an async upload needs to do several hops between
threads, in which case "AsyncRun" becomes hard to define.
I'd rather pass the callback to AsyncPixelTransferDelegate::AsyncTexImage2D with
the explicit semantic of "this callback is run as soon as the input buffer has
been consumed, possibly run on another thread", and have the implementation of
that semantic being the responsibility of each delegate (or manager).

[jadahl, 2014/02/08 09:18:25]

Sounds reasonable to pass the callback to AsyncTexImage2D, I'll update the patch
to do that.

[jadahl, 2014/02/09 11:54:52]

Reconsidering this, I think we still need something like this, because not every
AsyncTexImage2D command results in a call to Manager::AsyncTexImage2D (in case
of error), and we cannot write that upload token directly, but we don't want to
drop it because it'll block free:ing the memory until some successful upload.

+  virtual void AsyncRun(const base::Closure& callback) = 0;

[epennerAtGoogle, 2014/02/07 20:43:58]

This leads to duplicate work happening here where we notify the query and also
update the token. It's fine for this patch, but do you think we could use the
token in the client eventually to replace the queries being used?

[jadahl, 2014/02/08 09:18:25]

I'm thinking, can't we just handle those queries completely on the client side
after this?

+
   // There's no guarantee that callback will run on the caller thread.
   virtual void AsyncNotifyCompletion(
       const AsyncMemoryParams& mem_params,