gpu: Separate GpuControlService from GpuControl

gpu/command_buffer/service/gles2_cmd_decoder.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 "gpu/command_buffer/service/gles2_cmd_decoder.h"
 
 #include <stdio.h>
 
 #include <algorithm>
 #include <list>
@@ skipping 2671 matching lines @@
   caps.texture_storage = feature_info_->feature_flags().ext_texture_storage;
   caps.discard_framebuffer =
       feature_info_->feature_flags().ext_discard_framebuffer;
 
 #if defined(OS_MACOSX)
   // This is unconditionally true on mac, no need to test for it at runtime.
   caps.iosurface = true;
 #endif
 
   caps.post_sub_buffer = supports_post_sub_buffer_;
+  caps.map_image = !!image_manager();

[no sievers, 2014/04/23 23:57:29]

Shouldn't we always have an ImageManager (see ContextGroup constructor)?

reveman@ should comment on whether we need this capability to be passed from
service to client.

[boliu, 2014/04/24 00:04:02]

I was going to ask reveman too. The condition before this CL was
(image_manager() && gpu_memory_buffer_factory_), but factory is now a client
side concept.

But this change also doesn't matter for the cross-process context:
https://code.google.com/p/chromium/codesearch#chromium/src/content/common/gpu...

Either way, I don't want to be accidentally turning on zero-copy path for other
platforms.

[reveman, 2014/04/24 00:39:11]

I would like to remove this cap completely and require the service to always
implement it. I did this in https://codereview.chromium.org/205193006/ by
considering an implementation that always fails to allocate buffers a valid
implementation but piman wasn't a fan of that. I think we should just implement
this everywhere (pepper, mojo?) and remove the map_image capability.

What happens in the case of pepper with this change?

[boliu, 2014/04/24 01:30:56]

Pepper and mojo are not affected. They don't implement gpu memory buffers and
just returns the default Capabilities object, so not affected by this change.

gpu::Capabilities was added to help cc so it doesn't have to parse extension
strings. If cc has another mechanism to correct detect whether gpu memory
buffers are supported, then we can remove it now? For android, kEnableMapImage
is added only for webview and not chrome, so that should be ok already.

 
   return caps;
 }
 
 void GLES2DecoderImpl::UpdateCapabilities() {
   util_.set_num_compressed_texture_formats(
       validators_->compressed_texture_format.GetValues().size());
   util_.set_num_shader_binary_formats(
       validators_->shader_binary_format.GetValues().size());
 }
@@ skipping 8048 matching lines @@
   }
 }
 
 // Include the auto-generated part of this file. We split this because it means
 // we can easily edit the non-auto generated parts right here in this file
 // instead of having to edit some template or the code generator.
 #include "gpu/command_buffer/service/gles2_cmd_decoder_autogen.h"
 
 }  // namespace gles2
 }  // namespace gpu