Implemented new fence syncs which replaces the old sync points.

ppapi/proxy/ppapi_command_buffer_proxy.cc

Index: ppapi/proxy/ppapi_command_buffer_proxy.cc
diff --git a/ppapi/proxy/ppapi_command_buffer_proxy.cc b/ppapi/proxy/ppapi_command_buffer_proxy.cc
index 7a42524bff2fe2827ffbce153f9d62f1a011b108..05f4e1233f8e1cb3baae26ac01492eaf39277f56 100644
--- a/ppapi/proxy/ppapi_command_buffer_proxy.cc
+++ b/ppapi/proxy/ppapi_command_buffer_proxy.cc
@@ -163,6 +163,15 @@ void PpapiCommandBufferProxy::DestroyTransferBuffer(int32 id) {
       ppapi::API_ID_PPB_GRAPHICS_3D, resource_, id));
 }
 
+void PpapiCommandBufferProxy::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]

We will need to reflect the real channel_id/route_id here (or
FenceSyncNamespace), if we want to use the new sync point in pepper.
The way PpapiCommandBufferProxy works is that it forwards all command buffer
IPCs to the renderer, that then sends them to the GPU process using its own
channel. So channel_id and route_id are known on the renderer side at
initialization time, and it's just a matter of sending the FenceSyncNamespace in
the reply of PpapiHostMsg_PPBGraphics3D_Create. On the pepper side
(PPB_Graphics3D_Proxy::CreateProxyResource), it's just a matter of wiring it to
the PpapiCommandBufferProxy via Graphics3D::Init. On the renderer side
(PPB_Graphics3D_Proxy::OnMsgCreate), it's just a matter of passing it through
ResourceCreationImpl::CreateGraphics3DRaw -> PPB_Graphics3D_Impl::CreateRaw ->
PPB_Graphics3D_Impl::InitRaw and grabbing it there from command_buffer_.

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

Done.

+}
+
 uint32 PpapiCommandBufferProxy::CreateStreamTexture(uint32 texture_id) {
   NOTREACHED();
   return 0;