adds WARP support to Chromium, for Metro mode only, on Windows 8

Adds WARP support to Chromium on Windows 8+

Metro mode requires a GPU process but there are a few
tablets and other devices that don't have a GPU. Currently
we don't expose the menu option for Metro mode on these
devices. This CL exposes the Metro mode option for all
Windows 8+ machines, and if a GPU isn't normally available
it turns on WARP support for Metro mode only.

BUG=314954
Committed: https://crrev.com/862c1780c5b5c2df52f1b234d9c214cf6c25c4d1
Cr-Commit-Position: refs/heads/master@{#293267}

[luken, 2014-08-20 20:06:28]

zmo:

chrome\browser\gpu\
gpu\config\

brettw:
content\public\browser\gpu_data_manager.h

sky:
chrome\
ui\

Thanks

[Zhenyao Mo, 2014-08-20 21:02:09]

Mostly looks OK with a few minor issues that need to be addressed.

However, the win_gpu bot failure looks troublesome if it is caused by this CL. 
It looks like a half pixel different on the triangle edges.  Why this CL trigger
that difference?

https://codereview.chromium.org/435383002/diff/100001/chrome/browser/gpu/gpu_...
File chrome/browser/gpu/gpu_pref_manager.cc (right):

https://codereview.chromium.org/435383002/diff/100001/chrome/browser/gpu/gpu_...
chrome/browser/gpu/gpu_pref_manager.cc:22: GpuPrefManager::GpuPrefManager() {
You need to initialize use_warp_ here.

https://codereview.chromium.org/435383002/diff/100001/chrome/browser/gpu/gpu_...
chrome/browser/gpu/gpu_pref_manager.cc:81: local_state->CommitPendingWrite();
Is CommitPendingWrite() necessary?

https://codereview.chromium.org/435383002/diff/100001/content/browser/gpu/gpu...
File content/browser/gpu/gpu_data_manager_impl_private.cc (right):

https://codereview.chromium.org/435383002/diff/100001/content/browser/gpu/gpu...
content/browser/gpu/gpu_data_manager_impl_private.cc:475: gpu_info_.use_warp =
use_warp;
This is incorrect.  gpu_info_ could be updated multiple times during chrome
lifetime and this state will be lost.

You need a separate use_warp_ variable outside gpu_info_.

https://codereview.chromium.org/435383002/diff/100001/content/browser/gpu/gpu...
content/browser/gpu/gpu_data_manager_impl_private.cc:837: if
(gpu_info_.use_warp)
You should use ShouldUseWarp() here to be consistent.

https://codereview.chromium.org/435383002/diff/100001/ui/gl/gl_switches.cc
File ui/gl/gl_switches.cc (right):

https://codereview.chromium.org/435383002/diff/100001/ui/gl/gl_switches.cc#ne...
ui/gl/gl_switches.cc:80: kOverrideUseGLWithOSMesaForTests,
You need to include kUseWarp here if you want that switch to be passed down to
GPU process.

[sky, 2014-08-20 22:37:03]

You also need an observer in content/browser

https://codereview.chromium.org/435383002/diff/100001/chrome/browser/gpu/gpu_...
File chrome/browser/gpu/gpu_pref_manager.cc (right):

https://codereview.chromium.org/435383002/diff/100001/chrome/browser/gpu/gpu_...
chrome/browser/gpu/gpu_pref_manager.cc:80:
local_state->SetBoolean(prefs::kGPUUseWarp, use_warp_);
Why do we need to cache this in prefs? Can't we look it up at startup time?

https://codereview.chromium.org/435383002/diff/100001/chrome/browser/gpu/gpu_...
chrome/browser/gpu/gpu_pref_manager.cc:81: local_state->CommitPendingWrite();
On 2014/08/20 21:02:09, Zhenyao Mo wrote:
> Is CommitPendingWrite() necessary?

Also, do you really need to cache use_warp_? Can you always SetBoolean?

https://codereview.chromium.org/435383002/diff/100001/chrome/browser/lifetime...
File chrome/browser/lifetime/application_lifetime_win.cc (right):

https://codereview.chromium.org/435383002/diff/100001/chrome/browser/lifetime...
chrome/browser/lifetime/application_lifetime_win.cc:111: if
(!content::GpuDataManager::GetInstance()->GpuAccessAllowed(NULL)) {
nit: no {}

[luken, 2014-08-27 20:43:47]

PTAL. This version doesn't store a pref but determines fallback to Warp at
runtime. Not sure about the failed webGL pixel test, my code really shouldn't be
touching any of that.

https://codereview.chromium.org/435383002/diff/100001/chrome/browser/gpu/gpu_...
File chrome/browser/gpu/gpu_pref_manager.cc (right):

https://codereview.chromium.org/435383002/diff/100001/chrome/browser/gpu/gpu_...
chrome/browser/gpu/gpu_pref_manager.cc:22: GpuPrefManager::GpuPrefManager() {
On 2014/08/20 21:02:09, Zhenyao Mo wrote:
> You need to initialize use_warp_ here.

Deprecated code.

https://codereview.chromium.org/435383002/diff/100001/chrome/browser/gpu/gpu_...
chrome/browser/gpu/gpu_pref_manager.cc:80:
local_state->SetBoolean(prefs::kGPUUseWarp, use_warp_);
On 2014/08/20 22:37:03, sky wrote:
> Why do we need to cache this in prefs? Can't we look it up at startup time?

No longer cached. We now determine at startup time.

https://codereview.chromium.org/435383002/diff/100001/chrome/browser/gpu/gpu_...
chrome/browser/gpu/gpu_pref_manager.cc:81: local_state->CommitPendingWrite();
On 2014/08/20 21:02:09, Zhenyao Mo wrote:
> Is CommitPendingWrite() necessary?

Deprecated code.

https://codereview.chromium.org/435383002/diff/100001/chrome/browser/gpu/gpu_...
chrome/browser/gpu/gpu_pref_manager.cc:81: local_state->CommitPendingWrite();
On 2014/08/20 22:37:03, sky wrote:
> On 2014/08/20 21:02:09, Zhenyao Mo wrote:
> > Is CommitPendingWrite() necessary?
> 
> Also, do you really need to cache use_warp_? Can you always SetBoolean?

Deprecated code.

https://codereview.chromium.org/435383002/diff/100001/chrome/browser/lifetime...
File chrome/browser/lifetime/application_lifetime_win.cc (right):

https://codereview.chromium.org/435383002/diff/100001/chrome/browser/lifetime...
chrome/browser/lifetime/application_lifetime_win.cc:111: if
(!content::GpuDataManager::GetInstance()->GpuAccessAllowed(NULL)) {
On 2014/08/20 22:37:03, sky wrote:
> nit: no {}

Deprecated code.

https://codereview.chromium.org/435383002/diff/100001/content/browser/gpu/gpu...
File content/browser/gpu/gpu_data_manager_impl_private.cc (right):

https://codereview.chromium.org/435383002/diff/100001/content/browser/gpu/gpu...
content/browser/gpu/gpu_data_manager_impl_private.cc:475: gpu_info_.use_warp =
use_warp;
On 2014/08/20 21:02:09, Zhenyao Mo wrote:
> This is incorrect.  gpu_info_ could be updated multiple times during chrome
> lifetime and this state will be lost.
> 
> You need a separate use_warp_ variable outside gpu_info_.

Deprecated code.

https://codereview.chromium.org/435383002/diff/100001/content/browser/gpu/gpu...
content/browser/gpu/gpu_data_manager_impl_private.cc:837: if
(gpu_info_.use_warp)
On 2014/08/20 21:02:09, Zhenyao Mo wrote:
> You should use ShouldUseWarp() here to be consistent.

Done.

https://codereview.chromium.org/435383002/diff/100001/ui/gl/gl_switches.cc
File ui/gl/gl_switches.cc (right):

https://codereview.chromium.org/435383002/diff/100001/ui/gl/gl_switches.cc#ne...
ui/gl/gl_switches.cc:80: kOverrideUseGLWithOSMesaForTests,
On 2014/08/20 21:02:09, Zhenyao Mo wrote:
> You need to include kUseWarp here if you want that switch to be passed down to
> GPU process.

Done.

[Zhenyao Mo, 2014-08-27 20:48:42]

The failure on win_gpu bots is because it switched from DX11 to DX9.  It's
apparently caused by your CL.  I need to look deeper to say why.

[Zhenyao Mo, 2014-08-27 20:49:31]

zmo@chromium.org changed reviewers:
+ geofflang@chromium.org

[Zhenyao Mo, 2014-08-27 20:50:36]

Geoff, can you take a look at this CL and maybe you can shed some lights why
this CL caused the win gpu bot to fall back to DX9?  Usually they run with DX11.
 This caused some pixel difference.

http://chromium-browser-gpu-tests.commondatastorage.googleapis.com/view_test_...

[Geoff Lang, 2014-08-27 21:05:05]

https://codereview.chromium.org/435383002/diff/200001/ui/gl/gl_surface_egl.cc
File ui/gl/gl_surface_egl.cc (right):

https://codereview.chromium.org/435383002/diff/200001/ui/gl/gl_surface_egl.cc...
ui/gl/gl_surface_egl.cc:105: g_display = eglGetPlatformDisplayEXT(platform,
g_native_display, attributes);
You should check for the existence of the extensions before calling this. 
ANGLE_platform_angle and ANGLE_platform_angle_d3d (if using a D3D type enum).

https://codereview.chromium.org/435383002/diff/200001/ui/gl/gl_surface_win.cc
File ui/gl/gl_surface_win.cc (left):

https://codereview.chromium.org/435383002/diff/200001/ui/gl/gl_surface_win.cc...
ui/gl/gl_surface_win.cc:297: if
(!CommandLine::ForCurrentProcess()->HasSwitch(switches::kDisableD3D11))
It reverted to D3D9 because this logic was removed.

https://codereview.chromium.org/435383002/diff/200001/ui/gl/gl_surface_win.cc
File ui/gl/gl_surface_win.cc (right):

https://codereview.chromium.org/435383002/diff/200001/ui/gl/gl_surface_win.cc...
ui/gl/gl_surface_win.cc:322: return NULL;
Not supplying a platform type to eglGetPlatformDisplayEXT will cause it to use
the 'default' renderer which is D3D9.  This should really return a list of
platform types in a specific order to try until one succeeds.  It'll need to
check for the presence of the warp flag and the disable d3d11 flag.

[luken, 2014-08-27 21:38:17]

Hey Geoff thanks for your feedback, working on the gl_surface_win.cc code but
had a question on gl_surface_gl.cc, can you ptal?

https://codereview.chromium.org/435383002/diff/200001/ui/gl/gl_surface_egl.cc
File ui/gl/gl_surface_egl.cc (right):

https://codereview.chromium.org/435383002/diff/200001/ui/gl/gl_surface_egl.cc...
ui/gl/gl_surface_egl.cc:105: g_display = eglGetPlatformDisplayEXT(platform,
g_native_display, attributes);
On 2014/08/27 21:05:04, Geoff Lang wrote:
> You should check for the existence of the extensions before calling this. 
> ANGLE_platform_angle and ANGLE_platform_angle_d3d (if using a D3D type enum).

Don't you need the display object returned by
eglGetDisplay/eglGetPlatformDisplayEXT to call eglQueryString? Or is there
another way?

[Geoff Lang, 2014-08-28 13:45:54]

https://codereview.chromium.org/435383002/diff/200001/ui/gl/gl_surface_egl.cc
File ui/gl/gl_surface_egl.cc (right):

https://codereview.chromium.org/435383002/diff/200001/ui/gl/gl_surface_egl.cc...
ui/gl/gl_surface_egl.cc:105: g_display = eglGetPlatformDisplayEXT(platform,
g_native_display, attributes);
On 2014/08/27 21:38:17, luken wrote:
> On 2014/08/27 21:05:04, Geoff Lang wrote:
> > You should check for the existence of the extensions before calling this. 
> > ANGLE_platform_angle and ANGLE_platform_angle_d3d (if using a D3D type
enum).
> 
> Don't you need the display object returned by
> eglGetDisplay/eglGetPlatformDisplayEXT to call eglQueryString? Or is there
> another way?

Yea, you're able to use eglQueryString(EGL_NO_DISPLAY) if the
EGL_EXT_client_extensions is present.

[luken, 2014-08-28 23:50:33]

https://codereview.chromium.org/435383002/diff/200001/ui/gl/gl_surface_egl.cc
File ui/gl/gl_surface_egl.cc (right):

https://codereview.chromium.org/435383002/diff/200001/ui/gl/gl_surface_egl.cc...
ui/gl/gl_surface_egl.cc:105: g_display = eglGetPlatformDisplayEXT(platform,
g_native_display, attributes);
On 2014/08/28 13:45:54, Geoff Lang wrote:
> On 2014/08/27 21:38:17, luken wrote:
> > On 2014/08/27 21:05:04, Geoff Lang wrote:
> > > You should check for the existence of the extensions before calling this. 
> > > ANGLE_platform_angle and ANGLE_platform_angle_d3d (if using a D3D type
> enum).
> > 
> > Don't you need the display object returned by
> > eglGetDisplay/eglGetPlatformDisplayEXT to call eglQueryString? Or is there
> > another way?
> 
> Yea, you're able to use eglQueryString(EGL_NO_DISPLAY) if the
> EGL_EXT_client_extensions is present.

Cool, will do, thanks.

https://codereview.chromium.org/435383002/diff/200001/ui/gl/gl_surface_win.cc
File ui/gl/gl_surface_win.cc (left):

https://codereview.chromium.org/435383002/diff/200001/ui/gl/gl_surface_win.cc...
ui/gl/gl_surface_win.cc:297: if
(!CommandLine::ForCurrentProcess()->HasSwitch(switches::kDisableD3D11))
On 2014/08/27 21:05:05, Geoff Lang wrote:
> It reverted to D3D9 because this logic was removed.

Done.

https://codereview.chromium.org/435383002/diff/200001/ui/gl/gl_surface_win.cc
File ui/gl/gl_surface_win.cc (right):

https://codereview.chromium.org/435383002/diff/200001/ui/gl/gl_surface_win.cc...
ui/gl/gl_surface_win.cc:322: return NULL;
On 2014/08/27 21:05:05, Geoff Lang wrote:
> Not supplying a platform type to eglGetPlatformDisplayEXT will cause it to use
> the 'default' renderer which is D3D9.  This should really return a list of
> platform types in a specific order to try until one succeeds.  It'll need to
> check for the presence of the warp flag and the disable d3d11 flag.

Done.

[Zhenyao Mo, 2014-08-29 18:28:50]

gpu side mostly look good with a few minor comments/questions.

https://codereview.chromium.org/435383002/diff/240001/chrome/app/chrome_main.cc
File chrome/app/chrome_main.cc (right):

https://codereview.chromium.org/435383002/diff/240001/chrome/app/chrome_main....
chrome/app/chrome_main.cc:58:
CommandLine::ForCurrentProcess()->HasSwitch(switches::kViewerConnect));
It seems to me that we add ShouldFallbackToWarp() and SetShouldFallbackToWarp()
in an awkward place rather than gpu_data_manager, simply because the
kViewerConnect lives in chrome, not content.

Is it better to move this switch to the content side?  So the
ShoudFallbackToWarp can have a more natural implementation?

https://codereview.chromium.org/435383002/diff/240001/content/browser/gpu/gpu...
File content/browser/gpu/gpu_data_manager_impl_private.cc (right):

https://codereview.chromium.org/435383002/diff/240001/content/browser/gpu/gpu...
content/browser/gpu/gpu_data_manager_impl_private.cc:974: return;
Please add an unit test to make sure if Warp is used,
EnableSwiftShaderIfNecessary() doesn't truly enable SwiftShader.  This is not
apparent and we need to make sure people don't break it in the future.

https://codereview.chromium.org/435383002/diff/240001/gpu/config/gpu_info_col...
File gpu/config/gpu_info_collector_win.cc (right):

https://codereview.chromium.org/435383002/diff/240001/gpu/config/gpu_info_col...
gpu/config/gpu_info_collector_win.cc:636: static bool g_should_fallback_to_warp
= false;
I don't think static is necessary if it's inside anonymous namespace.

[luken, 2014-08-29 23:34:03]

https://codereview.chromium.org/435383002/diff/240001/chrome/app/chrome_main.cc
File chrome/app/chrome_main.cc (right):

https://codereview.chromium.org/435383002/diff/240001/chrome/app/chrome_main....
chrome/app/chrome_main.cc:58:
CommandLine::ForCurrentProcess()->HasSwitch(switches::kViewerConnect));
On 2014/08/29 18:28:50, Zhenyao Mo wrote:
> It seems to me that we add ShouldFallbackToWarp() and
SetShouldFallbackToWarp()
> in an awkward place rather than gpu_data_manager, simply because the
> kViewerConnect lives in chrome, not content.
> 
> Is it better to move this switch to the content side?  So the
> ShoudFallbackToWarp can have a more natural implementation?

I moved it. Since kViewerConnect needs to be used by delegate_execute the best
place I could find was ui_base_switches.

https://codereview.chromium.org/435383002/diff/240001/content/browser/gpu/gpu...
File content/browser/gpu/gpu_data_manager_impl_private.cc (right):

https://codereview.chromium.org/435383002/diff/240001/content/browser/gpu/gpu...
content/browser/gpu/gpu_data_manager_impl_private.cc:974: return;
On 2014/08/29 18:28:50, Zhenyao Mo wrote:
> Please add an unit test to make sure if Warp is used,
> EnableSwiftShaderIfNecessary() doesn't truly enable SwiftShader.  This is not
> apparent and we need to make sure people don't break it in the future.

Done.

https://codereview.chromium.org/435383002/diff/240001/gpu/config/gpu_info_col...
File gpu/config/gpu_info_collector_win.cc (right):

https://codereview.chromium.org/435383002/diff/240001/gpu/config/gpu_info_col...
gpu/config/gpu_info_collector_win.cc:636: static bool g_should_fallback_to_warp
= false;
On 2014/08/29 18:28:50, Zhenyao Mo wrote:
> I don't think static is necessary if it's inside anonymous namespace.

Deprecated code, but thanks for today's C++ fact learning!

[Zhenyao Mo, 2014-08-29 23:38:35]

gpu part LGTM

[luken, 2014-08-29 23:42:20]

luken@chromium.org changed reviewers:
+ cpu@chromium.org

[cpu_(ooo_6.6-7.5), 2014-08-30 00:03:00]

lgtm

[sky, 2014-09-02 17:09:04]

sky@chromium.org changed reviewers:
+ kbr@chromium.org

[sky, 2014-09-02 17:09:05]

I'm not a good reviewer for the ui/gl changes.
+kbr for ui/gl
The rest LGTM

[Ken Russell (switch to Gerrit), 2014-09-02 23:57:29]

https://codereview.chromium.org/435383002/diff/260001/ui/base/ui_base_switche...
File ui/base/ui_base_switches.cc (right):

https://codereview.chromium.org/435383002/diff/260001/ui/base/ui_base_switche...
ui/base/ui_base_switches.cc:49: const char kViewerConnect[] = "viewer-connect";
This name is confusing; I'd suggest something like --metro-viewer-connect or
--connect-to-metro-viewer.

https://codereview.chromium.org/435383002/diff/260001/ui/gl/gl_surface_win.cc
File ui/gl/gl_surface_win.cc (right):

https://codereview.chromium.org/435383002/diff/260001/ui/gl/gl_surface_win.cc...
ui/gl/gl_surface_win.cc:308: return GetDC(NULL);
Is GetDC(NULL) the correct return value when --disable-d3d11 is passed? How does
the behavior differ compared to the previous return value of
EGL_DEFAULT_DISPLAY?

[luken, 2014-09-03 00:58:07]

https://codereview.chromium.org/435383002/diff/260001/ui/base/ui_base_switche...
File ui/base/ui_base_switches.cc (right):

https://codereview.chromium.org/435383002/diff/260001/ui/base/ui_base_switche...
ui/base/ui_base_switches.cc:49: const char kViewerConnect[] = "viewer-connect";
On 2014/09/02 23:57:29, Ken Russell wrote:
> This name is confusing; I'd suggest something like --metro-viewer-connect or
> --connect-to-metro-viewer.

Sure, cpu@ approves a change of name to this flag. Were you OK with the rename
in the same CL that moves the flag (e.g. this one) or should I do that in a
subsequent CL?

https://codereview.chromium.org/435383002/diff/260001/ui/gl/gl_surface_win.cc
File ui/gl/gl_surface_win.cc (right):

https://codereview.chromium.org/435383002/diff/260001/ui/gl/gl_surface_win.cc...
ui/gl/gl_surface_win.cc:308: return GetDC(NULL);
On 2014/09/02 23:57:29, Ken Russell wrote:
> Is GetDC(NULL) the correct return value when --disable-d3d11 is passed? How
does
> the behavior differ compared to the previous return value of
> EGL_DEFAULT_DISPLAY?

It turns out that ANGLE always wants a valid DeviceContext passed in as the
EGLNativeDisplayType argument to eglGetDisplay(), but the ANGLE code isn't
enforcing the validity check on the DC for that function call. It is, however,
enforcing that validity check for eglGetDisplayEXT(), which we now call in the
case for warp. If you don't specify a platform type you get the default display
which is D3D9. So in the case of disabling d3d11 we are still requesting the
"default" D3D9 display, but in a slightly less invalid way.

[luken, 2014-09-03 20:59:31]

PTAL

https://codereview.chromium.org/435383002/diff/260001/ui/base/ui_base_switche...
File ui/base/ui_base_switches.cc (right):

https://codereview.chromium.org/435383002/diff/260001/ui/base/ui_base_switche...
ui/base/ui_base_switches.cc:49: const char kViewerConnect[] = "viewer-connect";
On 2014/09/03 00:58:07, luken wrote:
> On 2014/09/02 23:57:29, Ken Russell wrote:
> > This name is confusing; I'd suggest something like --metro-viewer-connect or
> > --connect-to-metro-viewer.
> 
> Sure, cpu@ approves a change of name to this flag. Were you OK with the rename
> in the same CL that moves the flag (e.g. this one) or should I do that in a
> subsequent CL?

Done.

[cpu_(ooo_6.6-7.5), 2014-09-03 22:02:18]

changing the name is fine. The viewer is not just for metro, for example it
works in windows 7 but whatever gets this CL going. please.

[Ken Russell (switch to Gerrit), 2014-09-03 22:28:51]

Sorry for the holdup and thanks for the clarification on the EGL issue. Please
follow up with geofflang@ to add any extra needed validation to ANGLE. ui/gl
LGTM

[luken, 2014-09-03 22:30:21]

The CQ bit was checked by luken@chromium.org

[Geoff Lang, 2014-09-03 22:46:05]

On 2014/09/03 00:58:07, luken wrote:
>
https://codereview.chromium.org/435383002/diff/260001/ui/base/ui_base_switche...
> File ui/base/ui_base_switches.cc (right):
> 
>
https://codereview.chromium.org/435383002/diff/260001/ui/base/ui_base_switche...
> ui/base/ui_base_switches.cc:49: const char kViewerConnect[] =
"viewer-connect";
> On 2014/09/02 23:57:29, Ken Russell wrote:
> > This name is confusing; I'd suggest something like --metro-viewer-connect or
> > --connect-to-metro-viewer.
> 
> Sure, cpu@ approves a change of name to this flag. Were you OK with the rename
> in the same CL that moves the flag (e.g. this one) or should I do that in a
> subsequent CL?
> 
> https://codereview.chromium.org/435383002/diff/260001/ui/gl/gl_surface_win.cc
> File ui/gl/gl_surface_win.cc (right):
> 
>
https://codereview.chromium.org/435383002/diff/260001/ui/gl/gl_surface_win.cc...
> ui/gl/gl_surface_win.cc:308: return GetDC(NULL);
> On 2014/09/02 23:57:29, Ken Russell wrote:
> > Is GetDC(NULL) the correct return value when --disable-d3d11 is passed? How
> does
> > the behavior differ compared to the previous return value of
> > EGL_DEFAULT_DISPLAY?
> 
> It turns out that ANGLE always wants a valid DeviceContext passed in as the
> EGLNativeDisplayType argument to eglGetDisplay(), but the ANGLE code isn't
> enforcing the validity check on the DC for that function call. It is, however,
> enforcing that validity check for eglGetDisplayEXT(), which we now call in the
> case for warp. If you don't specify a platform type you get the default
display
> which is D3D9. So in the case of disabling d3d11 we are still requesting the
> "default" D3D9 display, but in a slightly less invalid way.

ANGLE lets the invalid DC slide for eglGetDisplay because we need to accept the
special enums there.  We'll eventually remove support for them and only accept
valid DCs once chrome is no longer using them.  eglGetDisplayEXT requires a
valid DC because it does not accept the enums from EGL_ANGLE_direct3d_display.

[commit-bot: I haz the power, 2014-09-03 23:23:49]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/luken@chromium.org/435383002/280001

[commit-bot: I haz the power, 2014-09-04 01:30:37]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-09-04 01:30:38]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[luken, 2014-09-04 01:36:22]

luken@chromium.org changed reviewers:
+ piman@chromium.org

[luken, 2014-09-04 01:36:47]

+piman for OWNERS approval on content/public/browser/gpu_data_manager.h

[piman, 2014-09-04 02:18:22]

lgtm

[luken, 2014-09-04 05:09:27]

The CQ bit was checked by luken@chromium.org

[commit-bot: I haz the power, 2014-09-04 05:09:53]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/luken@chromium.org/435383002/280001

[commit-bot: I haz the power, 2014-09-04 05:36:26]

Committed patchset #15 (id:280001) as 13d04eb85b6f6c98d1de0331ad3d13d9850e31a5

[commit-bot: I haz the power, 2014-09-10 03:30:07]

Patchset 15 (id:??) landed as
https://crrev.com/862c1780c5b5c2df52f1b234d9c214cf6c25c4d1
Cr-Commit-Position: refs/heads/master@{#293267}