Partial raster for GPU

Partial raster for GPU

Partial raster allows for significant savings during raster by allowing us to
rasterize on top of the previous content, only updating the areas which have
changed.

In order to leverage this optimization, the resource containing the previous
content must be unused and available for writing. Currently, the GPU raster
path isn't able to effectively leverage this optimization, as in nearly all cases,
the previous content is still in use (being displayed by the browser), and
cannot be overwritten with new updates.

To allow GPU raster to better leverage partial raster, this causes us to track
invalidations to a given resource over multiple frames. This allows us to use a
resource from two frames ago in partial raster (as opposed to just the most
recent frame). Resources from >1 frame in the past have a much higher
likelihood of being unused.

While this approach isn't perfect (you can't partial raster on the first change,
only subsequent ones) there is virtually no cost to it, which makes it a nice
starting point. Other approaches, such as copying in-use resources may be
investigated in the future if this technique produces insufficient results
compared to Software's Partial Raster numbers.

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/5ac42f32e7b4142cd578082424a85a26794cf0ab
Cr-Commit-Position: refs/heads/master@{#405379}

[ericrk, 2016-06-30 20:56:39]

Description was changed from

==========
Partial raster for GPU

BUG=
==========

to

==========
Partial raster for GPU

BUG=
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[ericrk, 2016-07-11 17:38:57]

Patchset #3 (id:40001) has been deleted

[ericrk, 2016-07-11 17:39:05]

Patchset #1 (id:1) has been deleted

[ericrk, 2016-07-11 17:39:13]

Patchset #1 (id:20001) has been deleted

[ericrk, 2016-07-11 17:48:01]

Description was changed from

==========
Partial raster for GPU

BUG=
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
Partial raster for GPU

Partial raster allows for significant savings during raster by allowing us to
rasterize on top of the previous content, only updating the areas which have
changed.

In order to leverage this optimization, the resource containing the previous
content must be unused and available for writing. Currently, the GPU raster path
isn't able to effectively leverage this optimization, as in nearly all cases,
the previous content is still in use (being displayed by the browser), and
cannot be overwritten with new updates.

To allow GPU raster to better leverage partial raster, this causes us to track
invalidations to a given resource over multiple frames. This allows us to use a
resource from two frames ago in partial raster (as opposed to just the most
recent frame). Resources from >1 frame in the past have a much higher likelihood
of being unused.

While this approach isn't perfect (you can't partial raster on the first change,
only subsequent ones) there is virtually no cost to it, which makes it a nice
starting point. Other approaches, such as copying in-use resources may be
investigated in the future if this technique produces insufficient results
compared to Software's Partial Raster numbers.


BUG=
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[ericrk, 2016-07-11 17:49:07]

Description was changed from

==========
Partial raster for GPU

Partial raster allows for significant savings during raster by allowing us to
rasterize on top of the previous content, only updating the areas which have
changed.

In order to leverage this optimization, the resource containing the previous
content must be unused and available for writing. Currently, the GPU raster path
isn't able to effectively leverage this optimization, as in nearly all cases,
the previous content is still in use (being displayed by the browser), and
cannot be overwritten with new updates.

To allow GPU raster to better leverage partial raster, this causes us to track
invalidations to a given resource over multiple frames. This allows us to use a
resource from two frames ago in partial raster (as opposed to just the most
recent frame). Resources from >1 frame in the past have a much higher likelihood
of being unused.

While this approach isn't perfect (you can't partial raster on the first change,
only subsequent ones) there is virtually no cost to it, which makes it a nice
starting point. Other approaches, such as copying in-use resources may be
investigated in the future if this technique produces insufficient results
compared to Software's Partial Raster numbers.


BUG=
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
Partial raster for GPU

Partial raster allows for significant savings during raster by allowing us to
rasterize on top of the previous content, only updating the areas which have
changed.

In order to leverage this optimization, the resource containing the previous
content must be unused and available for writing. Currently, the GPU raster
path isn't able to effectively leverage this optimization, as in nearly all
cases,
the previous content is still in use (being displayed by the browser), and
cannot be overwritten with new updates.

To allow GPU raster to better leverage partial raster, this causes us to track
invalidations to a given resource over multiple frames. This allows us to use a
resource from two frames ago in partial raster (as opposed to just the most
recent frame). Resources from >1 frame in the past have a much higher
likelihood of being unused.

While this approach isn't perfect (you can't partial raster on the first change,
only subsequent ones) there is virtually no cost to it, which makes it a nice
starting point. Other approaches, such as copying in-use resources may be
investigated in the future if this technique produces insufficient results
compared to Software's Partial Raster numbers.

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[ericrk, 2016-07-11 18:54:50]

Patchset #1 (id:60001) has been deleted

[ericrk, 2016-07-11 18:55:29]

ericrk@chromium.org changed reviewers:
+ enne@chromium.org

[ericrk, 2016-07-11 18:55:30]

https://codereview.chromium.org/2110083004/diff/80001/cc/raster/one_copy_rast...
File cc/raster/one_copy_raster_buffer_provider.cc (right):

https://codereview.chromium.org/2110083004/diff/80001/cc/raster/one_copy_rast...
cc/raster/one_copy_raster_buffer_provider.cc:157: return false;
One copy doesn't support partial raster into a buffer provided by TileManager
(which is what this fn controls). Instead, it handles partial raster internally
in its staging buffers.

Could rename to "CanPartialRasterIntoProvidedBuffer"?

[enne (OOO), 2016-07-11 21:16:26]

https://codereview.chromium.org/2110083004/diff/80001/cc/raster/one_copy_rast...
File cc/raster/one_copy_raster_buffer_provider.cc (right):

https://codereview.chromium.org/2110083004/diff/80001/cc/raster/one_copy_rast...
cc/raster/one_copy_raster_buffer_provider.cc:157: return false;
On 2016/07/11 at 18:55:29, ericrk wrote:
> One copy doesn't support partial raster into a buffer provided by TileManager
> (which is what this fn controls). Instead, it handles partial raster
internally
> in its staging buffers.
> 
> Could rename to "CanPartialRasterIntoProvidedBuffer"?

I'm not sure I know what the best answer is, but I think it's weird to have this
return false.

https://codereview.chromium.org/2110083004/diff/80001/cc/resources/resource_p...
File cc/resources/resource_pool.cc (right):

https://codereview.chromium.org/2110083004/diff/80001/cc/resources/resource_p...
cc/resources/resource_pool.cc:199:
found_resource->set_content_id(new_content_id);
I guess this could mean that potentially there are two resources in the unused
pool with the same id in some cases, but that should be fine, I think? It just
means you'll find one first in the above case, and then maybe recycle the other
eventually.

However, what happens if the browser takes multiple frames to return resources
and so you have multiple resources in the in use pool with the same id?  Do you
need to update the invalidated rect on all of them and not just the first one
you find?

https://codereview.chromium.org/2110083004/diff/80001/cc/resources/resource_p...
File cc/resources/resource_pool_unittest.cc (right):

https://codereview.chromium.org/2110083004/diff/80001/cc/resources/resource_p...
cc/resources/resource_pool_unittest.cc:237: Resource* re_acquired_resource =
reacquired is one word, you don't need an underscore.  ;)

[ericrk, 2016-07-11 23:03:41]

Patchset #2 (id:90001) has been deleted

[ericrk, 2016-07-12 17:30:49]

Patchset #2 (id:110001) has been deleted

[ericrk, 2016-07-12 17:31:56]

Thanks for the feedback! updated.

https://codereview.chromium.org/2110083004/diff/80001/cc/raster/one_copy_rast...
File cc/raster/one_copy_raster_buffer_provider.cc (right):

https://codereview.chromium.org/2110083004/diff/80001/cc/raster/one_copy_rast...
cc/raster/one_copy_raster_buffer_provider.cc:157: return false;
On 2016/07/11 21:16:24, enne wrote:
> On 2016/07/11 at 18:55:29, ericrk wrote:
> > One copy doesn't support partial raster into a buffer provided by
TileManager
> > (which is what this fn controls). Instead, it handles partial raster
> internally
> > in its staging buffers.
> > 
> > Could rename to "CanPartialRasterIntoProvidedBuffer"?
> 
> I'm not sure I know what the best answer is, but I think it's weird to have
this
> return false.

Renamed this function to hopefully be clearer.

https://codereview.chromium.org/2110083004/diff/80001/cc/resources/resource_p...
File cc/resources/resource_pool.cc (right):

https://codereview.chromium.org/2110083004/diff/80001/cc/resources/resource_p...
cc/resources/resource_pool.cc:199:
found_resource->set_content_id(new_content_id);
On 2016/07/11 21:16:24, enne wrote:
> I guess this could mean that potentially there are two resources in the unused
> pool with the same id in some cases, but that should be fine, I think? It just
> means you'll find one first in the above case, and then maybe recycle the
other
> eventually.
> 
> However, what happens if the browser takes multiple frames to return resources
> and so you have multiple resources in the in use pool with the same id?  Do
you
> need to update the invalidated rect on all of them and not just the first one
> you find?

Per our offline discussion, added a comment to explain things more. Let me know
if this makes sense now.

https://codereview.chromium.org/2110083004/diff/80001/cc/resources/resource_p...
File cc/resources/resource_pool_unittest.cc (right):

https://codereview.chromium.org/2110083004/diff/80001/cc/resources/resource_p...
cc/resources/resource_pool_unittest.cc:237: Resource* re_acquired_resource =
On 2016/07/11 21:16:24, enne wrote:
> reacquired is one word, you don't need an underscore.  ;)

Done.

[enne (OOO), 2016-07-12 17:42:54]

lgtm

https://codereview.chromium.org/2110083004/diff/130001/cc/resources/resource_...
File cc/resources/resource_pool.cc (right):

https://codereview.chromium.org/2110083004/diff/130001/cc/resources/resource_...
cc/resources/resource_pool.cc:186: // Couldn't find an unused previous resource.
If possible, update the
Thanks for this.  :)

[ericrk, 2016-07-12 17:54:52]

The CQ bit was checked by ericrk@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-12 17:56:41]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-12 18:29:45]

The CQ bit was unchecked by commit-bot@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-12 18:29:46]

Dry run: Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[ericrk, 2016-07-13 22:50:01]

The CQ bit was checked by ericrk@chromium.org

[ericrk, 2016-07-13 22:50:01]

The patchset sent to the CQ was uploaded after l-g-t-m from enne@chromium.org
Link to the patchset: https://codereview.chromium.org/2110083004/#ps150001
(title: "Add missing resource cleanup to unit tests.")

[commit-bot: I haz the power, 2016-07-13 22:50:34]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-14 01:07:58]

Description was changed from

==========
Partial raster for GPU

Partial raster allows for significant savings during raster by allowing us to
rasterize on top of the previous content, only updating the areas which have
changed.

In order to leverage this optimization, the resource containing the previous
content must be unused and available for writing. Currently, the GPU raster
path isn't able to effectively leverage this optimization, as in nearly all
cases,
the previous content is still in use (being displayed by the browser), and
cannot be overwritten with new updates.

To allow GPU raster to better leverage partial raster, this causes us to track
invalidations to a given resource over multiple frames. This allows us to use a
resource from two frames ago in partial raster (as opposed to just the most
recent frame). Resources from >1 frame in the past have a much higher
likelihood of being unused.

While this approach isn't perfect (you can't partial raster on the first change,
only subsequent ones) there is virtually no cost to it, which makes it a nice
starting point. Other approaches, such as copying in-use resources may be
investigated in the future if this technique produces insufficient results
compared to Software's Partial Raster numbers.

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
Partial raster for GPU

Partial raster allows for significant savings during raster by allowing us to
rasterize on top of the previous content, only updating the areas which have
changed.

In order to leverage this optimization, the resource containing the previous
content must be unused and available for writing. Currently, the GPU raster
path isn't able to effectively leverage this optimization, as in nearly all
cases,
the previous content is still in use (being displayed by the browser), and
cannot be overwritten with new updates.

To allow GPU raster to better leverage partial raster, this causes us to track
invalidations to a given resource over multiple frames. This allows us to use a
resource from two frames ago in partial raster (as opposed to just the most
recent frame). Resources from >1 frame in the past have a much higher
likelihood of being unused.

While this approach isn't perfect (you can't partial raster on the first change,
only subsequent ones) there is virtually no cost to it, which makes it a nice
starting point. Other approaches, such as copying in-use resources may be
investigated in the future if this technique produces insufficient results
compared to Software's Partial Raster numbers.

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[commit-bot: I haz the power, 2016-07-14 01:07:59]

Committed patchset #3 (id:150001)

[commit-bot: I haz the power, 2016-07-14 01:08:21]

CQ bit was unchecked.

[commit-bot: I haz the power, 2016-07-14 01:11:44]

Description was changed from

==========
Partial raster for GPU

Partial raster allows for significant savings during raster by allowing us to
rasterize on top of the previous content, only updating the areas which have
changed.

In order to leverage this optimization, the resource containing the previous
content must be unused and available for writing. Currently, the GPU raster
path isn't able to effectively leverage this optimization, as in nearly all
cases,
the previous content is still in use (being displayed by the browser), and
cannot be overwritten with new updates.

To allow GPU raster to better leverage partial raster, this causes us to track
invalidations to a given resource over multiple frames. This allows us to use a
resource from two frames ago in partial raster (as opposed to just the most
recent frame). Resources from >1 frame in the past have a much higher
likelihood of being unused.

While this approach isn't perfect (you can't partial raster on the first change,
only subsequent ones) there is virtually no cost to it, which makes it a nice
starting point. Other approaches, such as copying in-use resources may be
investigated in the future if this technique produces insufficient results
compared to Software's Partial Raster numbers.

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
Partial raster for GPU

Partial raster allows for significant savings during raster by allowing us to
rasterize on top of the previous content, only updating the areas which have
changed.

In order to leverage this optimization, the resource containing the previous
content must be unused and available for writing. Currently, the GPU raster
path isn't able to effectively leverage this optimization, as in nearly all
cases,
the previous content is still in use (being displayed by the browser), and
cannot be overwritten with new updates.

To allow GPU raster to better leverage partial raster, this causes us to track
invalidations to a given resource over multiple frames. This allows us to use a
resource from two frames ago in partial raster (as opposed to just the most
recent frame). Resources from >1 frame in the past have a much higher
likelihood of being unused.

While this approach isn't perfect (you can't partial raster on the first change,
only subsequent ones) there is virtually no cost to it, which makes it a nice
starting point. Other approaches, such as copying in-use resources may be
investigated in the future if this technique produces insufficient results
compared to Software's Partial Raster numbers.

CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

Committed: https://crrev.com/5ac42f32e7b4142cd578082424a85a26794cf0ab
Cr-Commit-Position: refs/heads/master@{#405379}
==========

[commit-bot: I haz the power, 2016-07-14 01:11:45]

Patchset 3 (id:??) landed as
https://crrev.com/5ac42f32e7b4142cd578082424a85a26794cf0ab
Cr-Commit-Position: refs/heads/master@{#405379}