gpu: Thread-safe command buffer state lookup.

gpu/command_buffer/client/gpu_control.h

 // Copyright 2014 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_CLIENT_GPU_CONTROL_H_
 #define GPU_COMMAND_BUFFER_CLIENT_GPU_CONTROL_H_
 
 #include <stddef.h>
 #include <stdint.h>
 
@@ skipping 64 matching lines @@
   // The namespace and command buffer ID forms a unique pair for all existing
   // GpuControl (on client) and matches for the corresponding command buffer
   // (on server) in a single server process. The extra command buffer data can
   // be used for extra identification purposes. One usage is to store some
   // extra field to identify unverified sync tokens for the implementation of
   // the CanWaitUnverifiedSyncToken() function.
   virtual CommandBufferNamespace GetNamespaceID() const = 0;
   virtual CommandBufferId GetCommandBufferID() const = 0;
   virtual int32_t GetExtraCommandBufferData() const = 0;
 
-  // Fence Syncs use release counters at a context level, these fence syncs
-  // need to be flushed before they can be shared with other contexts across
-  // channels. Subclasses should implement these functions and take care of
-  // figuring out when a fence sync has been flushed. The difference between
-  // IsFenceSyncFlushed and IsFenceSyncFlushReceived, one is testing is the
-  // client has issued the flush, and the other is testing if the service
-  // has received the flush.
+  // Generates a fence sync which should be inserted into the GL command stream.
+  // When the service executes the fence sync it is released. Fence syncs are
+  // shared with other contexts as sync tokens which encapsulate the fence sync
+  // and the command buffer on which it was generated. Fence syncs need to be
+  // flushed before they can be used by other contexts. Furthermore, the flush
+  // must be verified before sending a sync token across channel boundaries.
   virtual uint64_t GenerateFenceSyncRelease() = 0;
+
+  // Returns true if the fence sync is valid.
   virtual bool IsFenceSyncRelease(uint64_t release) = 0;
+
+  // Returns true if the client has flushed the fence sync.
   virtual bool IsFenceSyncFlushed(uint64_t release) = 0;
+
+  // Returns true if the service has received the fence sync. Used for verifying
+  // sync tokens.
   virtual bool IsFenceSyncFlushReceived(uint64_t release) = 0;
 
+  // Returns true if the service has released (executed) the fence sync. Some
+  // implementations may support calling this from any thread without holding
+  // the lock provided by the client.

[piman, 2016/12/07 20:30:12]

Are there implementations that are not thread safe?
I think that would be problematic, because GLES2Implementation assumes it is -
at least if we want to claim that ContextSupport::IsFenceSyncReleased is
thread-safe. Do we need to add some introspection
(GpuControl::HasThreadSafeSupport()) so that we can at least DCHECK?

[sunnyps, 2016/12/08 01:14:15]

I made the InProcessCommandBuffer implementation thread-safe. Ppapi and test
only implementations, GLManager and MockClientGpuControl don't implement this
but they don't implement SetLock and a bunch of other things.

+  virtual bool IsFenceSyncReleased(uint64_t release) = 0;
+
   // Runs |callback| when sync token is signalled.
   virtual void SignalSyncToken(const SyncToken& sync_token,
                                const base::Closure& callback) = 0;
 
   // Under some circumstances a sync token may be used which has not been
   // verified to have been flushed. For example, fence syncs queued on the
   // same channel as the wait command guarantee that the fence sync will
   // be enqueued first so does not need to be flushed.
   virtual bool CanWaitUnverifiedSyncToken(const SyncToken* sync_token) = 0;
 
  private:
   DISALLOW_COPY_AND_ASSIGN(GpuControl);
 };
 
 }  // namespace gpu
 
 #endif  // GPU_COMMAND_BUFFER_CLIENT_GPU_CONTROL_H_