gpu: Refactor GpuMemoryBuffer framework for multi-process support.

gpu/command_buffer/common/command_buffer.h

Index: gpu/command_buffer/common/command_buffer.h
diff --git a/gpu/command_buffer/common/command_buffer.h b/gpu/command_buffer/common/command_buffer.h
index 3078bca2ba3af97db63fbdd5ecb9da0180d94cbd..080ce7039f78e6f70d597c42dea7ea31137b010d 100644
--- a/gpu/command_buffer/common/command_buffer.h
+++ b/gpu/command_buffer/common/command_buffer.h
@@ -13,6 +13,11 @@ namespace base {
 class SharedMemory;
 }
 
+namespace gfx {
+class GLImage;
+class GpuMemoryBuffer;
+}
+
 namespace gpu {
 
 // Common interface for CommandBuffer implementations.
@@ -141,6 +146,20 @@ class GPU_EXPORT CommandBuffer {
   // be used for cross-context synchronization.
   virtual uint32 InsertSyncPoint() = 0;
 
+  // Create a gpu memory buffer of the given dimensions and format. Returns

[kaanb, 2013/07/31 23:44:05]

optional: I prefer using third-person in comments, i.e. s/Create/Creates/ which
is the Java standard. You start with "Create" in the first sentence and
"Returns" in the second. It would be good to at least be consistent
Create/Return or Creates/Returns.

[reveman, 2013/08/01 13:32:18]

I prefer to keep it consistent with CreateTransferBuffer for now. We can change
all the comments in this file as a follow-up if we think that's important.

+  // its ID or -1 on error.
+  virtual gfx::GpuMemoryBuffer* CreateGpuMemoryBuffer(

[piman, 2013/08/01 21:19:30]

I would prefer if we didn't load up CommandBuffer with GL-y concepts and keep it
to the command processing level.

We have been talking about adding a separate interface that GLES2Implementation
(and higher level classes) can use to deal with things that don't go through
command buffers (e.g. IPCs, or accessing singletons when in-process). Maybe now
is the time to do it?

[no sievers, 2013/08/01 21:30:04]

Or can it just go through GpuCommandBufferStub?
We have other GL-y things (InsertSyncPoint, mailbox names) that send IPCs from
CommandBufferProxyImpl but get handled by the stub or channel on the other end.

I think it comes from the fact that CommandBufferProxyImpl implements two
things: it's a CommandBuffer but also the opposite end of a GpuCommandBufferStub
(which *owns* the CommandBufferService but does not derive from it). Not sure we
need to change things just for this?

Also, where I think David is coming from is that he is comparing 0-copy+ashmen
with transfer buffer pixel transfers. But I agree that we otherwise treat
GLImages and GpuMemoryBuffers more as a GL concept. One noticeable difference:
transfer buffer ids are not exposed to the client while the resource IDs for the
images/buffers are.

[reveman, 2013/08/08 23:19:00]

I've limited the CommandBuffer changes to adding Create/DestroyGpuMemoryBuffer
which I don't think of as GL specific.  But it sounds like we might still want
to add a separate interface for this. Any suggestions for what the name of this
interface should be?

+      size_t width,
+      size_t height,
+      unsigned internalformat,
+      int32* id) = 0;
+
+  // Destroy a gpu memory buffer. The ID must be positive.
+  virtual void DestroyGpuMemoryBuffer(int32 id) = 0;
+
+  // Get the image associated with an ID. Returns a null image for ID 0.
+  virtual gfx::GLImage* GetImage(int32 id) = 0;
+
  private:
   DISALLOW_COPY_AND_ASSIGN(CommandBuffer);
 };