Implemented new fence syncs which replaces the old sync points.

gpu/command_buffer/service/in_process_command_buffer.cc

Index: gpu/command_buffer/service/in_process_command_buffer.cc
diff --git a/gpu/command_buffer/service/in_process_command_buffer.cc b/gpu/command_buffer/service/in_process_command_buffer.cc
index 6997cecdbf2de82fd668b4f7155050e5790e0727..225d9ea4ddd727283f5d1db3f9ddcdddf1ee65e3 100644
--- a/gpu/command_buffer/service/in_process_command_buffer.cc
+++ b/gpu/command_buffer/service/in_process_command_buffer.cc
@@ -600,6 +600,15 @@ void InProcessCommandBuffer::DestroyTransferBuffer(int32 id) {
   QueueTask(task);
 }
 
+void InProcessCommandBuffer::GetRouteInformation(int* channel_id,
+                                                 uint32_t* route_id) {
+  if (channel_id)
+    *channel_id = 0;
+
+  if (route_id)
+    *route_id = 0;

[piman, 2015/09/10 23:55:32]

As mentioned above, we're going to need an implementation of the FenceSync
mechanism in this class as well (which combines both the client side and the
server side).


As you mention in the description, one key question is what should be the
channel_id/route_id pair for this. But related to what I said above, really what
we need them for is to look up the FenceSyncClient, so really it is simply a
globally-unique namespace... it doesn't have to be explicitly tied to a
GpuChannel/GpuCommandBufferStub, though it's nice if we can generate that
namespace from the client side without round-trip. So what we could do is:
- instead of an explicit channel_id/route_id, we could make it a semi-opaque
FenceSyncNamespace struct, that has 2 ids, which could be as generic as
"word1"/"word2" (but could be extended if we need more specificity, e.g. for
mojo).
- for CommandBufferProxyImpl, word1 would be the channel id, word2 would be the
route id
- for InProcessCommandBuffer, we'd need a unique word1 that's different than any
channel id, and we'd need a unique id for each InProcessCommandBuffer instance
  * for word1, we could make it a property of the
InProcessCommandBuffer::Service (which is shared across the various
InProcessCommandBuffers). If it is the default service (from the
GpuInProcessThreadHolder), it can simply be 0, since it doesn't share anything
with cross-process command buffers. If it is the injected one (created in
SynchronousCompositorFactoryImpl::GpuThreadService), we could create an id in
the same namespace as the channels, namely using
ChildProcessHostImpl::GenerateChildProcessUniqueId() (see e.g.
BrowserGpuChannelHostFactory)
  * for word2, we could make it either a globally unique id (using a
StaticAtomicSequenceNumber) or a counter in the InProcessCommandBuffer::Service
  * because InProcessCommandBuffer is both the client and the service side, the
same FenceSyncNamespace is available on both sides
- both the GpuCommandBufferStub and the InProcessCommandBuffer could register
themselves to the SyncPointManager using the FenceSyncNamespace directly
- SyncToken could then use a FenceSyncNamespace + release id.
- we don't have to talk about routes in gpu/command_buffer, which knows nothing
about it.

[David Yen, 2015/09/23 18:30:34]

Done.

+}
+
 void InProcessCommandBuffer::DestroyTransferBufferOnGpuThread(int32 id) {
   base::AutoLock lock(command_buffer_lock_);
   command_buffer_->DestroyTransferBuffer(id);
@@ -770,8 +779,13 @@ void InProcessCommandBuffer::RetireSyncPointOnGpuThread(uint32 sync_point) {
       base::AutoLock lock(command_buffer_lock_);
       make_current_success = MakeCurrent();
     }
-    if (make_current_success)
-      mailbox_manager->PushTextureUpdates(sync_point);
+    if (make_current_success) {
+      // Old sync points are global and not namespaced by gpu_channel &
+      // route_id. We can simply use the global sync point number as the
+      // release count with 0 for both gpu_channel and route_id. This will all
+      // be removed once the old sync points are replaced.
+      mailbox_manager->PushTextureUpdates(0, 0, sync_point);
+    }
   }
   service_->sync_point_manager()->RetireSyncPoint(sync_point);
 }
@@ -789,7 +803,11 @@ bool InProcessCommandBuffer::WaitSyncPointOnGpuThread(unsigned sync_point) {
   service_->sync_point_manager()->WaitSyncPoint(sync_point);
   gles2::MailboxManager* mailbox_manager =
       decoder_->GetContextGroup()->mailbox_manager();
-  mailbox_manager->PullTextureUpdates(sync_point);
+  // Old sync points are global and not namespaced by gpu_channel &
+  // route_id. We can simply use the global sync point number as the
+  // release count with 0 for both gpu_channel and route_id. This will all
+  // be removed once the old sync points are replaced.
+  mailbox_manager->PullTextureUpdates(0, 0, sync_point);
   return true;
 }