Added a unique command buffer ID for command buffers.

mojo/gles2/command_buffer_client_impl.cc

Index: mojo/gles2/command_buffer_client_impl.cc
diff --git a/mojo/gles2/command_buffer_client_impl.cc b/mojo/gles2/command_buffer_client_impl.cc
index b639f6e40472b2337f4fc5f3ec5040ea992ec3b7..f92f47e5588f1acb78a9d6b54ae65a9e863b7be2 100644
--- a/mojo/gles2/command_buffer_client_impl.cc
+++ b/mojo/gles2/command_buffer_client_impl.cc
@@ -393,4 +393,13 @@ bool CommandBufferClientImpl::IsGpuChannelLost() {
   return false;
 }
 
+gpu::CommandBufferNamespace CommandBufferClientImpl::GetNamespaceID() const {
+  return gpu::kCommandBufferNamespace_Mojo;
+}
+
+uint64_t CommandBufferClientImpl::GetCommandBufferID() const {
+  NOTIMPLEMENTED();

[rjkroege, 2015/09/16 18:55:22]

So, there must be a point to this CL or you wouldn't have added the code. :-)
So, what's going to go wrong in mandoline because all the command buffers are id
0? If having uniform cmd buffer ids of 0 is going to  break mandoline, I'd
really like you to implement this prior to landing.


Per my previous comment -- I think that there is a reasonably obvious namespace
id to give to a command buffer in mandoline that mirrors the way that we assign
ids to views: connection id concatenated with a per-client unique int.

[piman, 2015/09/16 20:18:07]

It's not currently used, as you can see.
It will be used for memory tracing (which I don't think mandoline does), and for
the new lightweight sync points whose API can be implemented on top of existing
sync points, and will probably have to be, for mojo.
What's a connection id, what's a view id? Where do they come from?
What about offscreen context that y'all just introduced for webgl?
https://codereview.chromium.org/1338433002/

Can we get help from the mandoline/mojo team to implement the mojo side of
things? It's becoming increasingly painful to make changes to command buffers
and cc when mojo gets in the way....

+  return 0;
+}
+
 }  // namespace gles2