Excessive raster work from picture shaders causes checkerboarding. |
|||||||||||
Issue description1. On an Android Go device (Alcatel in my case) load https://appsco.pe/ 2. Swipe sideways in the featured carousel Expceted: smooth animations and display of images Actual: scroll is a bit janky and images take a long time to update/display, showing white in the meantime. The trace seems to indicate that the GPU thread is pegged, and shows a main-thread-committed pending tree with a 1 second duration. In the meantime there are a number of impl-thread commits. It appears that the main-thread commits are getting starved. Trace attached.
,
Nov 6
Hi, any update on this? Sunny can you repro?
,
Nov 6
This is related to OOP-R. At first I suspected this is because of a failure to check the scheduler whether the context should yield. Those checks happen automatically after every 20 commands which suffices for GL command decoder, but isn't well suited to raster decoder since raster commands do a lot more work. For both GL and raster command decoders, we call ExitCommandProcessingEarly after some types of commands such as those involving texture uploads. We should do the same on EndRasterCHROMIUM perhaps. However, after taking a closer look at the trace, it seems the raster work that's taking time is required by the display compositor i.e. there are sync token dependencies. See the Scheduler::RunNextTask traces - if priority is "High", those tiles are required by display compositor. It'll need some investigation to figure out why the raster work is taking a long time. Unfortunately I don't have the cycles to investigate this. Adding some folks who're experts in this area.
,
Nov 6
Hmmm, it looks like the every single tile has to do a texture allocation for a different render target which is used in the main draw. I'll try to repro locally on a nexus5x to see what exactly we are drawing that required this. Don't have a go device. chrishtr@, can you try with oopr disabled too?
,
Nov 7
This isn't something oop specific. The render targets during raster are for picture shaders and it looks like each commit from blink comes with a new set of shaders which then have to be rasterized later in the pipeline. And I'm guessing all these raster heavy updates become noticeable on a low end device. From the point of view of raster, it looks like everything is working as expected. Chris, is there something we could do on paint invalidation side to avoid regenerating these shaders? Attaching a trace with GPU raster. You can see "PaintShader::MakePaintRecord" during the paint lifecycle phase with the id for them and the same shader being used for raster on the next pending tree on tile worker threads with the trace "DecodeRecordShader" followed by all the skia work.
|
|||||||||||
►
Sign in to add a comment |
|||||||||||
Comment 1 by enne@chromium.org
, Sep 28Status: Assigned (was: Untriaged)