Chrome Version: 69.0.3472.0
OS: OS X tested
The attached traces are from zooming in on usatoday.com with and without OOP-R. In the OOP-R case I'm consistently seeing a call to CommandBufferHelper::Flush inside RasterImplementation::RasterCHROMIUM.
|
Deleted:
trace_usatoday-oopr.json.gz
3.5 MB
|
|
trace_usatoday-oopr.json.gz
3.5 MB
Download
|
|
Deleted:
trace_usatoday-ganesh.json.gz
2.4 MB
|
|
trace_usatoday-ganesh.json.gz
2.4 MB
Download
|
Comment 1 by vmi...@chromium.org
, Jun 27 2018Here is the call-stack issuing the Flushes: gpu::raster::RasterImplementation::RasterCHROMIUM(...) gpu::raster::RasterImplementation::UnmapRasterCHROMIUM(long) gpu::ScopedTransferBufferPtr::Release() gpu::TransferBuffer::FreePendingToken(void*, unsigned int) gpu::CommandBufferHelper::Flush() gpu::CommandBufferProxyImpl::Flush(int) sunnyps@ and I looked at this briefly. We think it's auto flushing due to crossing a transfer buffer threshold. See TransferBuffer::bytes_since_last_flush_ and https://cs.chromium.org/chromium/src/gpu/command_buffer/client/transfer_buffer.cc?sq=package:chromium&g=0&l=94 The accounting for TransferBuffer::bytes_since_last_flush_ doesn't seem to account for the way OOP-R maps and then shrinks memory. We map a large size, then shrink it with TransferBuffer::ShrinkLastBlock().