Re-land: cc: Examine layers to determine if we're ready to activate.

Re-land: cc: Examine layers to determine if we're ready to activate.

This introduces a new mechanism for determining when
we're ready to activate the pending tree. The tile
priority is still used to determine when it's worth
waking up the compositor thread and evaluating if
we can activate. However, the actual check that
determines if we're ready to activate doesn't rely
on the state of scheduled raster tasks but is a
synchronous call on each layer.

The result is a pending tree activation mechanism that
is much easier to debug and validate for correctness,
while still providing the performance benefits of the
old mechanism by taking the "required to activate" field
of the tile priority into account when scheduling tasks.
 
BUG=375206
TEST=cc_unittests --gtest_filter=PictureLayerImplTest.AllTilesRequiredForActivationAreReadyToDraw

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=273040

[reveman, 2014-05-15 17:31:23]

Created this while doing some debugging and was hoping we could switch to
something like this to make pending tree activation easier to debug and
hopefully less buggy.

Not sure how well this performs. Tile counts could be added to speed this up if
necessary and the current stateless system for evaluating if we can activate
would then be useful to check correctness using DCHECKs.

I think we've in some ways come full circle here as we did something similar in
the early days of impl-side painting. The difference is that we now have the
"required_for_activation" state as part of the tile priority, which gives us a
very good idea of when it's worthwhile to evaluate if we can activate.

Wdyt?

[vmpstr, 2014-05-15 17:46:23]

I like this general approach. Assuming we can convince ourselves that this is
worth the performance hit, would this mean that we don't actually need counts
way of activating? Ie, if we feel that we might be ready to activate we can
always just schedule a check?

https://codereview.chromium.org/287643004/diff/40001/cc/resources/tile_manage...
File cc/resources/tile_manager.cc (left):

https://codereview.chromium.org/287643004/diff/40001/cc/resources/tile_manage...
cc/resources/tile_manager.cc:893: if (mts.visible_and_ready_to_draw &&
use_rasterize_on_demand_)
Why this change?

https://codereview.chromium.org/287643004/diff/40001/cc/resources/tile_manage...
File cc/resources/tile_manager.cc (right):

https://codereview.chromium.org/287643004/diff/40001/cc/resources/tile_manage...
cc/resources/tile_manager.cc:543: client_->NotifyTileInitialized(tile);
This means that we might end up calling NotifyTileInitialized multiple times
right? I mean it's a somewhat awkward state to deal with (rasterize_on_demand).
It causes us to be able to draw, but it also will need rasterization. I'm not
sure if it's correct to say it's been initialized or not, tbh.

[reveman, 2014-05-15 19:01:42]

I'm hoping that we can do this without adding counts as that's just some
additional state that could potentially be wrong and cause bugs. If we have to
add counts for performance, then I think we should still use this existing
stateless check to verify that the counts work correctly.

https://codereview.chromium.org/287643004/diff/40001/cc/resources/tile_manage...
File cc/resources/tile_manager.cc (left):

https://codereview.chromium.org/287643004/diff/40001/cc/resources/tile_manage...
cc/resources/tile_manager.cc:893: if (mts.visible_and_ready_to_draw &&
use_rasterize_on_demand_)
On 2014/05/15 17:46:23, vmpstr wrote:
> Why this change?

We can't handle situations where the renderer doesn't support on-demand in the
tile manager anymore as this not where we decide if tiles are ready.

https://codereview.chromium.org/287643004/diff/40001/cc/resources/tile_manage...
File cc/resources/tile_manager.cc (right):

https://codereview.chromium.org/287643004/diff/40001/cc/resources/tile_manage...
cc/resources/tile_manager.cc:543: client_->NotifyTileInitialized(tile);
On 2014/05/15 17:46:23, vmpstr wrote:
> This means that we might end up calling NotifyTileInitialized multiple times
> right? I mean it's a somewhat awkward state to deal with
(rasterize_on_demand).
> It causes us to be able to draw, but it also will need rasterization. I'm not
> sure if it's correct to say it's been initialized or not, tbh.

That's already the case as we have multiple tile versions but we might want to
change the name of this function to make this less confusing.
NotifyReadyToDrawStateChanged? The important part is that we can track damage
correctly.

[vmpstr, 2014-05-16 00:38:44]

https://codereview.chromium.org/287643004/diff/40001/cc/resources/tile_manage...
File cc/resources/tile_manager.cc (left):

https://codereview.chromium.org/287643004/diff/40001/cc/resources/tile_manage...
cc/resources/tile_manager.cc:893: if (mts.visible_and_ready_to_draw &&
use_rasterize_on_demand_)
On 2014/05/15 19:01:43, reveman wrote:
> On 2014/05/15 17:46:23, vmpstr wrote:
> > Why this change?
> 
> We can't handle situations where the renderer doesn't support on-demand in the
> tile manager anymore as this not where we decide if tiles are ready.

I don't follow. This part was there to prevent us from releasing active tree
visible tiles (or at least to immediatly replace them with rasterize on demand
content. I think the same applies if we don't support rasterize on demand,
except that we would flash/display checkerboard.

Besides, if rasterize on demand doesn't work, then how will this behave? Also,
should we call client_->NotifyReadyToDrawStateChanged? (we should probably name
this something entirely different since in the case of versions, we didn't
change the draw state, we just changed which resource we're using to draw)

https://codereview.chromium.org/287643004/diff/40001/cc/resources/tile_manage...
File cc/resources/tile_manager.cc (right):

https://codereview.chromium.org/287643004/diff/40001/cc/resources/tile_manage...
cc/resources/tile_manager.cc:543: client_->NotifyTileInitialized(tile);
On 2014/05/15 19:01:43, reveman wrote:
> On 2014/05/15 17:46:23, vmpstr wrote:
> > This means that we might end up calling NotifyTileInitialized multiple times
> > right? I mean it's a somewhat awkward state to deal with
> (rasterize_on_demand).
> > It causes us to be able to draw, but it also will need rasterization. I'm
not
> > sure if it's correct to say it's been initialized or not, tbh.
> 
> That's already the case as we have multiple tile versions but we might want to
> change the name of this function to make this less confusing.
> NotifyReadyToDrawStateChanged? The important part is that we can track damage
> correctly.

Fair enough. I agree that with versions it should probably be a different name.
Also tile versions make the counts hard to maintain, so I'm glad that we won't
need them.

https://codereview.chromium.org/287643004/diff/40001/cc/resources/tile_manage...
cc/resources/tile_manager.cc:1624: for
(std::vector<PictureLayerImpl*>::const_iterator it = layers_.begin();
This is probably dependent on my patch that clears layers that are not in RSLL.
That patch in part depends on another part, so it might be a couple of days
before that lands.

https://codereview.chromium.org/287643004/diff/40001/cc/resources/tile_manage...
cc/resources/tile_manager.cc:1635: if (check_if_ready_to_activate_pending_)
As an aside, this pattern seems to be in a few places:

ScheduleCheck
  if already_scheduled:
    return
  schedule and post
  already_scheduled = true

Is it worth it to extract that into UniqueNotification or something like that,
where it would take a task as a constructor/setting and then you just have to do
UniqueNotification un(task); un.Schedule(); or something?

[reveman, 2014-05-16 16:50:13]

I renamed NotifyTileInitialized to NotifyTileStateChanged in latest patch. PTAL.

https://codereview.chromium.org/287643004/diff/40001/cc/resources/tile_manage...
File cc/resources/tile_manager.cc (left):

https://codereview.chromium.org/287643004/diff/40001/cc/resources/tile_manage...
cc/resources/tile_manager.cc:893: if (mts.visible_and_ready_to_draw &&
use_rasterize_on_demand_)
On 2014/05/16 00:38:45, vmpstr wrote:
> On 2014/05/15 19:01:43, reveman wrote:
> > On 2014/05/15 17:46:23, vmpstr wrote:
> > > Why this change?
> > 
> > We can't handle situations where the renderer doesn't support on-demand in
the
> > tile manager anymore as this not where we decide if tiles are ready.
> 
> I don't follow. This part was there to prevent us from releasing active tree
> visible tiles (or at least to immediatly replace them with rasterize on demand
> content. I think the same applies if we don't support rasterize on demand,
> except that we would flash/display checkerboard.

This patch just moves the awareness of support for raster-on-demand to the
layer. As far as the tile manager knows. Raster-on-demand is now always
supported. The layer will simply avoid to generate on-demand quads if not
supported by the Renderer. The critical part is that the layer knows the
difference between a "real" checkboard tile and an on-demand tile that just
happens to be checkboard because the renderer doesn't support anything else.
That's needed for the layer to be able to determine if it's in a state where
it's ready to be activated.

> 
> Besides, if rasterize on demand doesn't work, then how will this behave? 

The result will be the same as before. The tile will be marked as on-demand but
the layer will produce a checkerboard quad for it as on-demand is not supported.

Also,
> should we call client_->NotifyReadyToDrawStateChanged? (we should probably
name
> this something entirely different since in the case of versions, we didn't
> change the draw state, we just changed which resource we're using to draw)

Yes, calling NotifyTileStateChanged here makes sense. I changed this a bit in
latest patch to make sure this client callback is now issued whenever the tile
state changes in a way that might affect output.

https://codereview.chromium.org/287643004/diff/40001/cc/resources/tile_manage...
File cc/resources/tile_manager.cc (right):

https://codereview.chromium.org/287643004/diff/40001/cc/resources/tile_manage...
cc/resources/tile_manager.cc:1624: for
(std::vector<PictureLayerImpl*>::const_iterator it = layers_.begin();
On 2014/05/16 00:38:45, vmpstr wrote:
> This is probably dependent on my patch that clears layers that are not in
RSLL.
> That patch in part depends on another part, so it might be a couple of days
> before that lands.

Yes, we should hold off on this until that lands.

https://codereview.chromium.org/287643004/diff/40001/cc/resources/tile_manage...
cc/resources/tile_manager.cc:1635: if (check_if_ready_to_activate_pending_)
On 2014/05/16 00:38:45, vmpstr wrote:
> As an aside, this pattern seems to be in a few places:
> 
> ScheduleCheck
>   if already_scheduled:
>     return
>   schedule and post
>   already_scheduled = true
> 
> Is it worth it to extract that into UniqueNotification or something like that,
> where it would take a task as a constructor/setting and then you just have to
do
> UniqueNotification un(task); un.Schedule(); or something?

Yes, that would be nice and we can probably bake the weak ptr stuff into that
too. This would be a separate patch though.

[vmpstr, 2014-05-16 17:09:06]

lgtm % enne and % the other patches landing

https://codereview.chromium.org/287643004/diff/40001/cc/resources/tile_manage...
File cc/resources/tile_manager.cc (left):

https://codereview.chromium.org/287643004/diff/40001/cc/resources/tile_manage...
cc/resources/tile_manager.cc:893: if (mts.visible_and_ready_to_draw &&
use_rasterize_on_demand_)
On 2014/05/16 16:50:13, reveman wrote:
> On 2014/05/16 00:38:45, vmpstr wrote:
> > On 2014/05/15 19:01:43, reveman wrote:
> > > On 2014/05/15 17:46:23, vmpstr wrote:
> > > > Why this change?
> > > 
> > > We can't handle situations where the renderer doesn't support on-demand in
> the
> > > tile manager anymore as this not where we decide if tiles are ready.
> > 
> > I don't follow. This part was there to prevent us from releasing active tree
> > visible tiles (or at least to immediatly replace them with rasterize on
demand
> > content. I think the same applies if we don't support rasterize on demand,
> > except that we would flash/display checkerboard.
> 
> This patch just moves the awareness of support for raster-on-demand to the
> layer. As far as the tile manager knows. Raster-on-demand is now always
> supported. The layer will simply avoid to generate on-demand quads if not
> supported by the Renderer. The critical part is that the layer knows the
> difference between a "real" checkboard tile and an on-demand tile that just
> happens to be checkboard because the renderer doesn't support anything else.
> That's needed for the layer to be able to determine if it's in a state where
> it's ready to be activated.
> 
> > 
> > Besides, if rasterize on demand doesn't work, then how will this behave? 
> 
> The result will be the same as before. The tile will be marked as on-demand
but
> the layer will produce a checkerboard quad for it as on-demand is not
supported.
> 
> Also,
> > should we call client_->NotifyReadyToDrawStateChanged? (we should probably
> name
> > this something entirely different since in the case of versions, we didn't
> > change the draw state, we just changed which resource we're using to draw)
> 
> Yes, calling NotifyTileStateChanged here makes sense. I changed this a bit in
> latest patch to make sure this client callback is now issued whenever the tile
> state changes in a way that might affect output.
> 

Oh, I missed the bit where it's handled in AppendQuads. Thanks for the
explanation.

https://codereview.chromium.org/287643004/diff/60001/cc/layers/picture_layer_...
File cc/layers/picture_layer_impl.cc (right):

https://codereview.chromium.org/287643004/diff/60001/cc/layers/picture_layer_...
cc/layers/picture_layer_impl.cc:278: .allow_rasterize_on_demand) {
can you flip this if:

if (!...)
  break;

...

Also, can you add a flag similar to had_checkerboard_quads so that we can see in
traces when we draw what would be a rasterize on demand, but instead
checkerboard because we don't support it?

https://codereview.chromium.org/287643004/diff/60001/cc/resources/tile_manage...
File cc/resources/tile_manager.cc (right):

https://codereview.chromium.org/287643004/diff/60001/cc/resources/tile_manage...
cc/resources/tile_manager.cc:675:
FreeResourcesForTileAndNotifyClientIfTileWasReadyToDraw(tile);
yay 56 character function names :P

[enne (OOO), 2014-05-16 21:18:32]

I think this is not unreasonable given the direction that vmpstr is taking
things to make layers more in control.  Eventually, tile manager will not know
all of the tiles, so the layers will probably need to do this anyway.

https://codereview.chromium.org/287643004/diff/60001/cc/layers/layer_impl.h
File cc/layers/layer_impl.h (right):

https://codereview.chromium.org/287643004/diff/60001/cc/layers/layer_impl.h#n...
cc/layers/layer_impl.h:191: virtual void NotifyTileStateChanged(const Tile*
tile) {}
StateChanged is very vague.  What was wrong with Initialized?  What about
ReadyToDraw?  Could you leave a comment here about when this should be called or
what caveats you're worried about?

https://codereview.chromium.org/287643004/diff/60001/cc/layers/picture_layer_...
File cc/layers/picture_layer_impl.cc (left):

https://codereview.chromium.org/287643004/diff/60001/cc/layers/picture_layer_...
cc/layers/picture_layer_impl.cc:250: if (!*iter || !iter->IsReadyToDraw()) {
What is the change to AppendQuads for? It's very hard to follow the diff.

https://codereview.chromium.org/287643004/diff/60001/cc/layers/picture_layer_...
File cc/layers/picture_layer_impl.cc (right):

https://codereview.chromium.org/287643004/diff/60001/cc/layers/picture_layer_...
cc/layers/picture_layer_impl.cc:1357: for
(PictureLayerTilingSet::CoverageIterator iter(
Sorry but I think this is not correct.

What you need to do is iterate through both the high and low res tilings with
the tiling iterator, but keep the same body of the for loop.

The coverage iterator is really just for drawing.  If a tile is not ready to
draw (and may be required), it will not return it in the iteration, and will
fall back to some non-ideal tile at a different scale.  Therefore, you can skip
over required tiles that are not ready.

Please add a unit test for this case, if you don't mind.

[vmpstr, 2014-05-19 22:05:35]

FYI, the required patch that cleans up layers has landed.

[reveman, 2014-05-21 22:11:39]

PTAL

https://codereview.chromium.org/287643004/diff/60001/cc/layers/layer_impl.h
File cc/layers/layer_impl.h (right):

https://codereview.chromium.org/287643004/diff/60001/cc/layers/layer_impl.h#n...
cc/layers/layer_impl.h:191: virtual void NotifyTileStateChanged(const Tile*
tile) {}
On 2014/05/16 21:18:32, enne wrote:
> StateChanged is very vague.  What was wrong with Initialized?  What about
> ReadyToDraw?  Could you leave a comment here about when this should be called
or
> what caveats you're worried about?

This needs to be called whenever the state of the tile changed in a way that
might cause a visible difference. Examples are:

1. Tile version having been initialized.
2. Higher priority tile version having been initialized.
3. Tile resources freed.
4. Tile marked for on-demand raster.

Initialized or ReadyToDraw doesn't seem right. I added a comment to the client
interface. If you have a better suggestion for name let me know.

https://codereview.chromium.org/287643004/diff/60001/cc/layers/picture_layer_...
File cc/layers/picture_layer_impl.cc (left):

https://codereview.chromium.org/287643004/diff/60001/cc/layers/picture_layer_...
cc/layers/picture_layer_impl.cc:250: if (!*iter || !iter->IsReadyToDraw()) {
On 2014/05/16 21:18:32, enne wrote:
> What is the change to AppendQuads for? It's very hard to follow the diff.

This is just moving the code and adding the allow_rasterize_on_demand check to
picture_pile_mode as "IsReadyToDraw" no longer means we can draw the tile. We
need to checkerboard if the tile version is in picture_pile_mode and renderer
doesn't allow on-demand raster.

https://codereview.chromium.org/287643004/diff/60001/cc/layers/picture_layer_...
File cc/layers/picture_layer_impl.cc (right):

https://codereview.chromium.org/287643004/diff/60001/cc/layers/picture_layer_...
cc/layers/picture_layer_impl.cc:278: .allow_rasterize_on_demand) {
On 2014/05/16 17:09:06, vmpstr wrote:
> can you flip this if:
> 
> if (!...)
>   break;
> 
> ...
> 
> Also, can you add a flag similar to had_checkerboard_quads so that we can see
in
> traces when we draw what would be a rasterize on demand, but instead
> checkerboard because we don't support it?

Done.

https://codereview.chromium.org/287643004/diff/80001/cc/layers/picture_layer_...
File cc/layers/picture_layer_impl.cc (right):

https://codereview.chromium.org/287643004/diff/80001/cc/layers/picture_layer_...
cc/layers/picture_layer_impl.cc:1387: tiling, contents_scale_x(), rect);
Using CoverageIterator here but maybe it would be better to add a
RequiredForActivationIterator instead?

[enne (OOO), 2014-05-21 22:19:31]

lgtm % vmpstr

https://codereview.chromium.org/287643004/diff/80001/cc/layers/picture_layer_...
File cc/layers/picture_layer_impl.cc (right):

https://codereview.chromium.org/287643004/diff/80001/cc/layers/picture_layer_...
cc/layers/picture_layer_impl.cc:1387: tiling, contents_scale_x(), rect);
On 2014/05/21 22:11:40, reveman wrote:
> Using CoverageIterator here but maybe it would be better to add a
> RequiredForActivationIterator instead?

I'm not sure it's worth adding yet another iterator.  There'd still be a split
between the marking and the iterating function, which is really the redundancy
that would worry me.

[vmpstr, 2014-05-21 22:28:30]

lgtm with nit + test request

https://codereview.chromium.org/287643004/diff/80001/cc/layers/picture_layer_...
File cc/layers/picture_layer_impl.cc (right):

https://codereview.chromium.org/287643004/diff/80001/cc/layers/picture_layer_...
cc/layers/picture_layer_impl.cc:358: "PictureLayerImpl::AppendQuads missing",
nit: I'd still prefer the word "checkerboard" since it's easy to search for that
in traces. Maybe "count" can change to "missing_tile_count" and
"on_demand_missing_tile_count" or something like that?

https://codereview.chromium.org/287643004/diff/80001/cc/layers/picture_layer_...
File cc/layers/picture_layer_impl_unittest.cc (right):

https://codereview.chromium.org/287643004/diff/80001/cc/layers/picture_layer_...
cc/layers/picture_layer_impl_unittest.cc:2364: TEST_F(PictureLayerImplTest,
AllTilesRequiredForActivationAreReadyToDraw) {
Can you add a similar test where you first mark all high res as done but not low
res? That's the case where we were activating before (since we skipped low res
in GetTilesWithAssignedBins)

[reveman, 2014-05-22 20:47:48]

https://codereview.chromium.org/287643004/diff/80001/cc/layers/picture_layer_...
File cc/layers/picture_layer_impl.cc (right):

https://codereview.chromium.org/287643004/diff/80001/cc/layers/picture_layer_...
cc/layers/picture_layer_impl.cc:358: "PictureLayerImpl::AppendQuads missing",
On 2014/05/21 22:28:30, vmpstr wrote:
> nit: I'd still prefer the word "checkerboard" since it's easy to search for
that
> in traces. Maybe "count" can change to "missing_tile_count" and
> "on_demand_missing_tile_count" or something like that?

Done.

https://codereview.chromium.org/287643004/diff/80001/cc/layers/picture_layer_...
File cc/layers/picture_layer_impl_unittest.cc (right):

https://codereview.chromium.org/287643004/diff/80001/cc/layers/picture_layer_...
cc/layers/picture_layer_impl_unittest.cc:2364: TEST_F(PictureLayerImplTest,
AllTilesRequiredForActivationAreReadyToDraw) {
On 2014/05/21 22:28:30, vmpstr wrote:
> Can you add a similar test where you first mark all high res as done but not
low
> res? That's the case where we were activating before (since we skipped low res
> in GetTilesWithAssignedBins)

Done.

[reveman, 2014-05-22 20:48:00]

The CQ bit was checked by reveman@chromium.org

[commit-bot: I haz the power, 2014-05-22 20:49:57]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/reveman@chromium.org/287643004/120001

[reveman, 2014-05-23 00:05:11]

The CQ bit was checked by reveman@chromium.org

[commit-bot: I haz the power, 2014-05-23 00:06:17]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/reveman@chromium.org/287643004/130001

[commit-bot: I haz the power, 2014-05-23 03:27:30]

FYI, CQ is re-trying this CL (attempt #1).
Please consider checking whether the failures are real,
and report flakes to chrome-troopers@google.com.
The failing builders are:
  android_dbg_triggered_tests on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/android_dbg_triggered...)
  linux_chromium_chromeos_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_chrome...)
  linux_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_rel/bu...)
  mac_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/mac_chromium_rel/buil...)
  win_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_rel/buil...)
  win_chromium_x64_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_x64_rel/...)
  linux_gpu_triggered_tests on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/linux_gpu_trigger...)

[commit-bot: I haz the power, 2014-05-23 04:14:51]

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

[commit-bot: I haz the power, 2014-05-23 04:14:51]

Try jobs failed on following builders:
  linux_gpu_triggered_tests on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/linux_gpu_trigger...)

[reveman, 2014-05-23 12:50:10]

The CQ bit was checked by reveman@chromium.org

[commit-bot: I haz the power, 2014-05-23 12:50:20]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/reveman@chromium.org/287643004/130001

[commit-bot: I haz the power, 2014-05-23 16:35:04]

FYI, CQ is re-trying this CL (attempt #1).
Please consider checking whether the failures are real,
and report flakes to chrome-troopers@google.com.
The failing builders are:
  android_dbg_triggered_tests on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/android_dbg_triggered...)
  linux_chromium_chromeos_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_chrome...)
  linux_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/linux_chromium_rel/bu...)
  mac_chromium_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/mac_chromium_rel/buil...)
  win_chromium_x64_rel on tryserver.chromium
(http://build.chromium.org/p/tryserver.chromium/builders/win_chromium_x64_rel/...)
  linux_gpu_triggered_tests on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/linux_gpu_trigger...)

[commit-bot: I haz the power, 2014-05-23 17:19:05]

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

[commit-bot: I haz the power, 2014-05-23 17:19:06]

Try jobs failed on following builders:
  linux_gpu_triggered_tests on tryserver.chromium.gpu
(http://build.chromium.org/p/tryserver.chromium.gpu/builders/linux_gpu_trigger...)

[reveman, 2014-05-23 20:21:48]

The CQ bit was checked by reveman@chromium.org

[commit-bot: I haz the power, 2014-05-23 20:22:45]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/reveman@chromium.org/287643004/150001

[commit-bot: I haz the power, 2014-05-23 23:35:41]

Change committed as 272635

[reveman, 2014-05-27 21:24:07]

The CQ bit was checked by reveman@chromium.org

[commit-bot: I haz the power, 2014-05-27 21:25:45]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/reveman@chromium.org/287643004/150001

[commit-bot: I haz the power, 2014-05-27 21:28:16]

Change committed as 273040