ozone: gpu: Add plumbing for platform-specific gpu messaging

content/browser/gpu/gpu_process_host.cc

 // Copyright (c) 2012 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.
 
 #include "content/browser/gpu/gpu_process_host.h"
 
 #include "base/base64.h"
 #include "base/base_switches.h"
 #include "base/basictypes.h"
 #include "base/bind.h"
@@ skipping 508 matching lines @@
     in_process_gpu_thread_->Start();
 
     OnProcessLaunched();  // Fake a callback that the process is ready.
   } else if (!LaunchGpuProcess(channel_id)) {
     return false;
   }
 
   if (!Send(new GpuMsg_Initialize()))
     return false;
 
+#if defined(USE_OZONE)
+  int32 host_route_id = GenerateRouteID();

[alexst (slow to review), 2014/06/16 21:34:23]

This is a public function that seems to only be used here and only on the IO
thread, is there a reason you chose to use AtomicSequenceNumber?

[rjkroege, 2014/06/16 21:38:49]

you are presuming that we never call this code more than once / gpu process
instance. Is this valid?

[piman, 2014/06/16 23:53:14]

What is the purpose of the host route id?
1- GenerateRouteID is only called once, so this will always be 1
2- you're sending back a gpu route id, can't you use that same id?

More generally, it seems that you have only one GpuPlatformSupport{Host,}, do
you need routing IDs at all?

[spang, 2014/06/17 14:47:34]

Right. I thought of making it a constant, and we can definitely still do that -
I was just aiming to be consistent with GpuChannelHost.
We could. If we say that the ids for both ends are in the same namespace, then
that would work, but the browser could not set up a route for itself without a
round trip to the GPU process. That's not a problem for this so we can certainly
do it.
We simply need a way to ensure the common GPU code does not attempt to handle
our messages, and instead hands them off to the platform code. That's all I'm
using the routing ids for.

Should we attach our own filter instead, and handle just the platform messages?
We should be able to avoid the routing ids that way.

+  if (!Send(new GpuMsg_InitializePlatformSupport(host_route_id)))

[piman, 2014/06/16 23:53:14]

Can you combine this with the GpuMsg_Initialize message?

Can you also combine GpuHostMsg_PlatformSupportInitialized with
GpuHostMsg_Initialized, and use RouteOnUIThread to forward to the UI shim?

[spang, 2014/06/17 14:47:34]

Will merge them.

+    return false;
+#endif
+
   return true;
 }
 
 void GpuProcessHost::RouteOnUIThread(const IPC::Message& message) {
   BrowserThread::PostTask(
       BrowserThread::UI,
       FROM_HERE,
       base::Bind(&RouteToGpuProcessHostUIShimTask, host_id_, message));
 }
 
@@ skipping 543 matching lines @@
   return shader_prefix_key_;
 }
 
 void GpuProcessHost::LoadedShader(const std::string& key,
                                   const std::string& data) {
   std::string prefix = GetShaderPrefixKey();
   if (!key.compare(0, prefix.length(), prefix))
     Send(new GpuMsg_LoadedShader(data));
 }
 
+int32 GpuProcessHost::GenerateRouteID() {
+  return next_route_id_.GetNext();
+}
+
 void GpuProcessHost::CreateChannelCache(int32 client_id) {
   TRACE_EVENT0("gpu", "GpuProcessHost::CreateChannelCache");
 
   scoped_refptr<ShaderDiskCache> cache =
       ShaderCacheFactory::GetInstance()->Get(client_id);
   if (!cache.get())
     return;
 
   cache->set_host_id(host_id_);
 
@@ skipping 11 matching lines @@
   TRACE_EVENT0("gpu", "GpuProcessHost::OnCacheShader");
   ClientIdToShaderCacheMap::iterator iter =
       client_id_to_shader_cache_.find(client_id);
   // If the cache doesn't exist then this is an off the record profile.
   if (iter == client_id_to_shader_cache_.end())
     return;
   iter->second->Cache(GetShaderPrefixKey() + ":" + key, shader);
 }
 
 }  // namespace content