gpu: Implement the new fence syncs in mojo command buffer.

components/mus/gles2/command_buffer_driver.cc

Index: components/mus/gles2/command_buffer_driver.cc
diff --git a/components/mus/gles2/command_buffer_driver.cc b/components/mus/gles2/command_buffer_driver.cc
index 649216a4fb71e8df6e476de135a9516d0c2d13f0..2157ef790e31542e818f117517b0a1b1392b82e2 100644
--- a/components/mus/gles2/command_buffer_driver.cc
+++ b/components/mus/gles2/command_buffer_driver.cc
@@ -4,6 +4,7 @@
 
 #include "components/mus/gles2/command_buffer_driver.h"
 
+#include "base/atomic_sequence_num.h"
 #include "base/bind.h"
 #include "base/macros.h"
 #include "base/memory/shared_memory.h"
@@ -35,10 +36,19 @@
 
 namespace mus {
 
+namespace {
+
+base::StaticAtomicSequenceNumber g_next_command_buffer_id;
+
+}
+
 CommandBufferDriver::Client::~Client() {}
 
 CommandBufferDriver::CommandBufferDriver(scoped_refptr<GpuState> gpu_state)
-    : client_(nullptr), gpu_state_(gpu_state), weak_factory_(this) {}
+    : command_buffer_id_(g_next_command_buffer_id.GetNext()),

[David Yen, 2015/11/19 18:12:52]

This needs to be globally unique across all processes. Are all of these drivers
only created on a single process?

From what I heard isn't there some sort of mojo unique client id we can use?

[David Yen, 2015/11/20 00:47:13]

After reviewing the other CL this looks okay to me now as long as all the
interacting command buffers will always be in the same process.

[Peng, 2015/11/20 17:41:15]

Yes. All drivers are in the same process (mus process).

+      client_(nullptr),
+      gpu_state_(gpu_state),
+      weak_factory_(this) {}
 
 CommandBufferDriver::~CommandBufferDriver() {
   DestroyDecoder();
@@ -56,7 +66,10 @@ void CommandBufferDriver::Initialize(
   mojom::GpuCapabilitiesPtr capabilities =
       success ? mojom::GpuCapabilities::From(decoder_->GetCapabilities())
               : nullptr;
-  sync_client_->DidInitialize(success, capabilities.Pass());
+  sync_client_->DidInitialize(success,
+                              gpu::CommandBufferNamespace::MOJO,
+                              command_buffer_id_,
+                              capabilities.Pass());
 }
 
 bool CommandBufferDriver::MakeCurrent() {
@@ -113,6 +126,10 @@ bool CommandBufferDriver::DoInitialize(
   decoder_.reset(::gpu::gles2::GLES2Decoder::Create(context_group.get()));
   scheduler_.reset(new gpu::GpuScheduler(command_buffer_.get(), decoder_.get(),
                                          decoder_.get()));
+  sync_point_order_data_ = gpu::SyncPointOrderData::Create();

[David Yen, 2015/11/19 18:12:52]

So this order data is used to order all commands, when a command is received and
before it is enqueued an order number should be assigned to the command using
"GenerateUnprocessedOrderNumber()".

Upon processing the command that order number should be passed into
"BeginProcessingOrderNumber()" and when it is done it should be passed into
"FinishProcessingOrderNumber()".

[Peng, 2015/11/20 17:41:15]

Seems the SyncPointOrderData is used for verifying fence release. But for tasks
submitted to CommandBufferTaskRunner, we don't guarantee those tasks will be
executed in the submitted order. So I am not sure if the OrderData is still
useful for us.

piman, could you please give me some suggestion?

[David Yen, 2015/11/20 18:20:06]

The OrderData must live per driver, but the generation should be done on the
CommandBufferTaskRunner. I would recommend adding it in "PostTask()".

So while you have the lock, you do something such as:
driver->sync_order_data()->AllocateOrderNum()

then you attach that order number to the TaskCallback. TaskCallback can be
something such as std::pair<callback, uint32>. Then in RunOneTaskInternalLocked
before callback.Run() you would do:
it->sync_order_data()->BeginProcessingOrderNumber(order_num);

and after if(complete) you would do:
it->sync_order_data()->FinishProcessingOrderNumber(order_num);

[Peng, 2015/11/20 20:32:15]

Done.

+  sync_point_client_ = gpu_state_->sync_point_manager()->CreateSyncPointClient(
+      sync_point_order_data_, gpu::CommandBufferNamespace::MOJO,
+      command_buffer_id_);
   decoder_->set_engine(scheduler_.get());
   decoder_->SetWaitSyncPointCallback(base::Bind(
       &CommandBufferDriver::OnWaitSyncPoint, base::Unretained(this)));
@@ -299,12 +316,8 @@ bool CommandBufferDriver::OnWaitSyncPoint(uint32_t sync_point) {
 }
 
 void CommandBufferDriver::OnFenceSyncRelease(uint64_t release) {
-  // TODO(dyen): Implement once CommandBufferID has been figured out and
-  // we have a SyncPointClient. It would probably look like what is commented
-  // out below:
-  // if (!sync_point_client_->client_state()->IsFenceSyncReleased(release))
-  //   sync_point_client_->ReleaseFenceSync(release);
-  NOTIMPLEMENTED();
+  if (!sync_point_client_->client_state()->IsFenceSyncReleased(release))
+    sync_point_client_->ReleaseFenceSync(release);
 }
 
 bool CommandBufferDriver::OnWaitFenceSync(
@@ -324,16 +337,13 @@ bool CommandBufferDriver::OnWaitFenceSync(
   if (release_state->IsFenceSyncReleased(release))
     return true;
 
-  // TODO(dyen): Implement once CommandBufferID has been figured out and
-  // we have a SyncPointClient. It would probably look like what is commented
-  // out below:
-  // scheduler_->SetScheduled(false);
-  // sync_point_client_->Wait(
-  //     release_state.get(),
-  //     release,
-  //     base::Bind(&CommandBufferDriver::OnSyncPointRetired,
-  //                weak_factory_.GetWeakPtr()));
-  NOTIMPLEMENTED();
+
+  scheduler_->SetScheduled(false);
+  sync_point_client_->Wait(
+      release_state.get(),
+      release,
+      base::Bind(&CommandBufferDriver::OnSyncPointRetired,
+                 weak_factory_.GetWeakPtr()));
   return scheduler_->scheduled();
 }