gpu: Refactor GpuMemoryBuffer framework for multi-process support.

gpu/command_buffer/common/command_buffer.h

 // Copyright (c) 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.
 
 #ifndef GPU_COMMAND_BUFFER_COMMON_COMMAND_BUFFER_H_
 #define GPU_COMMAND_BUFFER_COMMON_COMMAND_BUFFER_H_
 
 #include "gpu/command_buffer/common/buffer.h"
 #include "gpu/command_buffer/common/constants.h"
 #include "gpu/gpu_export.h"
 
 namespace base {
 class SharedMemory;
 }
 
+namespace gfx {
+class GLImage;
+class GpuMemoryBuffer;
+}
+
 namespace gpu {
 
 // Common interface for CommandBuffer implementations.
 class GPU_EXPORT CommandBuffer {
  public:
   struct State {
     State()
         : num_entries(0),
           get_offset(0),
           put_offset(0),
@@ skipping 108 matching lines @@
   // RendererGLContext::MakeCurrent prior to every GL call. It saves returning 6
   // ints redundantly when only the error is needed for the CommandBufferProxy
   // implementation.
   virtual error::Error GetLastError();
 #endif
 
   // Inserts a sync point, returning its ID. Sync point IDs are global and can
   // 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);
 };
 
 }  // namespace gpu
 
 #endif  // GPU_COMMAND_BUFFER_COMMON_COMMAND_BUFFER_H_