Added a way for sync point clients to issue out of order waits.

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 b2588b47a2cb2f0048c03d3fca665b4b1ea9f69e..968149b0dab63fa01ca66f623f3197898907582e 100644
--- a/gpu/command_buffer/service/in_process_command_buffer.cc
+++ b/gpu/command_buffer/service/in_process_command_buffer.cc
@@ -949,8 +949,8 @@ void InProcessCommandBuffer::SignalSyncTokenOnGpuThread(
     return;
   }
 
-  sync_point_client_->Wait(release_state.get(), sync_token.release_count(),
-                           WrapCallback(callback));
+  sync_point_client_->WaitOutOfOrder(

[piman, 2016/01/07 01:16:22]

ditto, how is this different than WaitFenceSyncOnGpuThread in terms of ordering?

[David Yen, 2016/01/07 18:40:58]

Here because order numbers are only generated in Flush(), even though
SignalSyncToken is run "in order" it does not have a proper order number
associated with the wait. Since WaitFenceSyncOnGpuThread is called by the
decoder it is properly managed.

Another way to solve this (since we do not currently support descheduling which
means they currently happen to run in order) is to also generate an order number
here around the Wait(), but WaitOutOfOrder() is simpler I think. This also opens
up the possibility of being able to deschedule commands.

+      release_state.get(), sync_token.release_count(), WrapCallback(callback));
 }
 
 void InProcessCommandBuffer::SignalQuery(unsigned query_id,