Image decode scheduling for checkered images. |
||
Issue descriptionAs we go through tiles in priority order, the current version of CheckerImageTracker would queue decodes for all images being checkered with the decode service. The decode service queues up all requests and runs them sequentially. This means the priority for these image decodes may not remain aligned with tile priorities if we can't re-order this queue for image decode requests. The tracker could internally maintain a queue, that gets re-built each time a PrepareTiles is done and has only one pending request to the decode service.
,
Apr 14 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/757e34b1e982b37a0333c87b3cd4184bd712c5b5 commit 757e34b1e982b37a0333c87b3cd4184bd712c5b5 Author: khushalsagar <khushalsagar@chromium.org> Date: Fri Apr 14 20:58:55 2017 cc: Create raster tasks in AssignGpuMemoryToTiles. Currently the raster task creation is done in TileManager::ScheduleTasks, which is after all the prioritized work has been created in AssignGpuMemoryToTiles. In order to align the prioritization of images decoded by the CheckerImageTracker, we need to create a decode queue for images decoded by the tracker as we iterate through the tiles in raster priority order. This is done in AssignGpuMemoryToTiles. In the case of checker-imaged tiles, we don't need to add them to tiles_to_raster since they have a valid resource. But we do need to decode images currently being checkered on them. Since the priorities for checker-imaged tiles and tiles requiring raster are interleaved, the analysis for images and building of the decode queue needs to be done during the iteration for all tiles. This change moves raster task creation, where the image analysis is performed, from ScheduleTasks to AssignGpuMemoryToTiles. Since ScheduleTasks only iterates through tiles_to_raster while AssignGpuMemoryToTiles will iterate through both, tiles requiring raster and checker-imaged tiles. BUG= 689184 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2822493003 Cr-Commit-Position: refs/heads/master@{#464792} [modify] https://crrev.com/757e34b1e982b37a0333c87b3cd4184bd712c5b5/cc/tiles/tile_manager.cc
,
Apr 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3e256c223b5c4057b6a9e0556041cdb8ba11c029 commit 3e256c223b5c4057b6a9e0556041cdb8ba11c029 Author: khushalsagar <khushalsagar@chromium.org> Date: Fri Apr 21 04:49:04 2017 cc: Optimize decode scheduling for checker-images. The CheckerImageTracker currently schedules image decodes for all checkered images as we schedule raster work for the dependent tiles. Once image decodes have been submitted to the tracker, they can not be cancelled and the order can not be changed. This means that as tile priorities change, the order in which images are decoded may not be aligned with the priority of the tiles which depend on them. Instead use a queue for scheduling decode work in the tracker. Only one outstanding decode is pending with the decode service at a time, and the queue is re-build each time we schedule work for a new set of tiles. This requires plumbing through the checker-imaged tiles in the RasterWorkerQueue since they are now inter-leaved with tiles that actually need to be rasterized. BUG= 689184 CQ_INCLUDE_TRYBOTS=master.tryserver.blink:linux_trusty_blink_rel Review-Url: https://codereview.chromium.org/2726343004 Cr-Commit-Position: refs/heads/master@{#466261} [modify] https://crrev.com/3e256c223b5c4057b6a9e0556041cdb8ba11c029/cc/test/fake_layer_tree_host_impl.h [modify] https://crrev.com/3e256c223b5c4057b6a9e0556041cdb8ba11c029/cc/test/fake_layer_tree_host_impl_client.cc [modify] https://crrev.com/3e256c223b5c4057b6a9e0556041cdb8ba11c029/cc/test/fake_layer_tree_host_impl_client.h [modify] https://crrev.com/3e256c223b5c4057b6a9e0556041cdb8ba11c029/cc/test/fake_recording_source.h [modify] https://crrev.com/3e256c223b5c4057b6a9e0556041cdb8ba11c029/cc/test/test_layer_tree_host_base.cc [modify] https://crrev.com/3e256c223b5c4057b6a9e0556041cdb8ba11c029/cc/test/test_layer_tree_host_base.h [modify] https://crrev.com/3e256c223b5c4057b6a9e0556041cdb8ba11c029/cc/tiles/checker_image_tracker.cc [modify] https://crrev.com/3e256c223b5c4057b6a9e0556041cdb8ba11c029/cc/tiles/checker_image_tracker.h [modify] https://crrev.com/3e256c223b5c4057b6a9e0556041cdb8ba11c029/cc/tiles/checker_image_tracker_unittest.cc [modify] https://crrev.com/3e256c223b5c4057b6a9e0556041cdb8ba11c029/cc/tiles/picture_layer_tiling.cc [modify] https://crrev.com/3e256c223b5c4057b6a9e0556041cdb8ba11c029/cc/tiles/picture_layer_tiling.h [modify] https://crrev.com/3e256c223b5c4057b6a9e0556041cdb8ba11c029/cc/tiles/prioritized_tile.cc [modify] https://crrev.com/3e256c223b5c4057b6a9e0556041cdb8ba11c029/cc/tiles/prioritized_tile.h [modify] https://crrev.com/3e256c223b5c4057b6a9e0556041cdb8ba11c029/cc/tiles/tile.h [modify] https://crrev.com/3e256c223b5c4057b6a9e0556041cdb8ba11c029/cc/tiles/tile_draw_info.cc [modify] https://crrev.com/3e256c223b5c4057b6a9e0556041cdb8ba11c029/cc/tiles/tile_draw_info.h [modify] https://crrev.com/3e256c223b5c4057b6a9e0556041cdb8ba11c029/cc/tiles/tile_manager.cc [modify] https://crrev.com/3e256c223b5c4057b6a9e0556041cdb8ba11c029/cc/tiles/tile_manager.h [modify] https://crrev.com/3e256c223b5c4057b6a9e0556041cdb8ba11c029/cc/tiles/tile_manager_unittest.cc [modify] https://crrev.com/3e256c223b5c4057b6a9e0556041cdb8ba11c029/cc/tiles/tiling_set_raster_queue_all.cc [modify] https://crrev.com/3e256c223b5c4057b6a9e0556041cdb8ba11c029/cc/tiles/tiling_set_raster_queue_all.h
,
Apr 21 2017
|
||
►
Sign in to add a comment |
||
Comment 1 by khushals...@chromium.org
, Feb 10 2017