Understanding One Copy Raster

[Khushal Sagar]

Hey everyone,

Nathan and I have been digging into the OneCopyRasterBufferProvider and it seems like the flow isn't what we expected it to be. The context is crbug.com/984045 about avoiding additional copies that came up on this patch.

We assumed the idea was to raster into shared memory and upload directly to tile resources that can be used for compositing. But the flow we're seeing in the code is as follows:

1) The renderer uses skia to raster a tile into shared memory using a GMB. We try to do partial raster here if we can reuse an old buffer (here).

2) The renderer notifies the GPU of the shm update using SharedImageInterface::UpdateSharedImage here. This is important since the next time a caller tries to BeginAccess on the GL representation for this GMB's shared image, it will trigger a texture upload here.

3) The renderer uses CopySubTexture to trigger uploading the update in shared memory to the destination texture (here). This call copies chunks at a time which I assumed was so the upload was interruptible service side?

Another interesting thing here was that we copy the full tile even for the partial raster case which I didn't expect.

3) On the GPU service side, CopySubTexture lands here for the GL case which uploads to the tile resource. But another upload was already triggered when read access was opened for the GMB backed image here. So we're doing multiple uploads of this memory to different textures.

The passthrough case doesn't have any special handling for GMBs so we get a GPU->GPU copy here, after an upload similarly triggered by read access on the shared image.

So did the one copy path regress with redundant uploads/copies somewhere along the way, or are we missing something here? Also, is the skia copy code-path in CopySubTexture any different from the passthrough one in the current code?

Thanks.
Khushal

[Sunny Sachanandani]

> Another interesting thing here was that we copy the full tile even for the partial raster case which I didn't expect.

Did a bit of code archeology and it looks like it's always been this way since partial raster was first implemented: https://source.chromium.org/chromium/chromium/src/+/master:cc/raster/one_copy_raster_buffer_provider.cc;l=356;drf=cc%2Fraster%2Fone_copy_tile_task_worker_pool.cc;drc=e0b5478e9fd582c904d1968726c437fd365ab3ea;bpv=1;bpt=0

> 3) On the GPU service side, CopySubTexture lands here for the GL case which uploads to the tile resource. But another upload was already triggered when read access was opened for the GMB backed image here. So we're doing multiple uploads of this memory to different textures.

This might have happened with the shared image migration.  Previously, when using the GL command buffer for the copy, the upload wouldn't happen.  In general, the GL command decoder only automatically uploads before the texture is used in a draw, but the GL shared image backing does that always if UpdateSharedImage() is called.

> So did the one copy path regress with redundant uploads/copies somewhere along the way, or are we missing something here? Also, is the skia copy code-path in CopySubTexture any different from the passthrough one in the current code?

The Skia shared image representation just calls BeginAccess() on the GL representation so it should be the same with respect to uploading the texture: https://source.chromium.org/chromium/chromium/src/+/master:gpu/command_buffer/service/shared_image_representation_skia_gl.cc;l=125

[Khushal Sagar]

On Wed, Oct 28, 2020 at 3:10 PM Sunny Sachanandani <sun...@chromium.org> wrote:

> Another interesting thing here was that we copy the full tile even for the partial raster case which I didn't expect.

Did a bit of code archeology and it looks like it's always been this way since partial raster was first implemented: https://source.chromium.org/chromium/chromium/src/+/master:cc/raster/one_copy_raster_buffer_provider.cc;l=356;drf=cc%2Fraster%2Fone_copy_tile_task_worker_pool.cc;drc=e0b5478e9fd582c904d1968726c437fd365ab3ea;bpv=1;bpt=0

> 3) On the GPU service side, CopySubTexture lands here for the GL case which uploads to the tile resource. But another upload was already triggered when read access was opened for the GMB backed image here. So we're doing multiple uploads of this memory to different textures.

This might have happened with the shared image migration.  Previously, when using the GL command buffer for the copy, the upload wouldn't happen.  In general, the GL command decoder only automatically uploads before the texture is used in a draw, but the GL shared image backing does that always if UpdateSharedImage() is called.

Thanks for clarifying Sunny. Nathan is looking into fixing this to avoid the redundant uploads/copies for the skia version of CopySubTexture in RasterDecoder. It'll also help simplify the code since we can remove the GL/ANGLE versions there.

[Rahul Patel]

Hi Sagar,

  

Thanks for brining this and i hope this would have fixed by now.

one quick confirmation: 

If we enable the here zero_copy_raster_buffer_provider  in that scenario raster operation would happen to GPU memory directly, so basically avoiding one copy in the shared_memory ? 

BTW, if we enable the zero_copy_raster_buffer_provider in that scenario it is expected to see reduction in the runtime memory ~4MB, and performance?

[Rahul Patel]

Could anyone please confirm please, by default OneCopyRasterBufferProvider was enabled in my codebase, however due to performance and memory improvement we thought of enabling the 

zeroCopyRasterBufferProvider here, but unfortunately doesn't see any improvement though. 

is it expected, or am i missing anything here?

On Thursday, October 29, 2020 at 7:17:58 PM UTC-7 Khushal Sagar wrote:

[Sunny Sachanandani]

Hi Rahul,

Can you clarify what platform you are testing on?

Each platform has performance characteristics and restrictions that determine which raster path makes sense.  Zero copy raster is only used on platforms which support CPU mappable GPU memory buffers (aka GMBs) and where GPU raster isn't supported or is blocklisted.

What zero copy raster does is use Skia in the renderer process to raster into CPU mapped GMBs as opposed to one copy raster which uses Skia to raster into CPU memory which is later uploaded to GPU textures.

In practice, zero copy raster would only be used on older ChromeOS devices which have support for CPU mappable GMBs but also have GPU raster blocklisted.  On other platforms that don't have CPU mappable GMBs, zero copy raster wouldn't have much benefit and would likely be less performant than GPU raster or one copy raster.

Hope this helps.

- Sunny

[Sunny Sachanandani]

Adding back graphics-dev@ so that this discussion is useful to others.

>  How would I know if GPU raster isn't supported or is blacklisted

By checking chrome://gpu (look for Rasterization under Graphics Feature Status) or by looking up your GPU model/driver in software_rendering_list.json (look for gpu_rasterization).

> CPU mappable GPU memory buffers (aka GMBs) supported or not

That's under "GpuMemoryBuffers Status" in chrome://gpu - it needs to be something other than "Software only".

On Mon, Mar 7, 2022 at 4:07 PM Rahul Patel <patelrah...@gmail.com> wrote:

Hi Sunny,

Thanks for your reply and clear explanation!

I was testing it through the content_shell and running it from my linux desktop machine.

• How would I know if GPU raster isn't supported or is blacklisted,  or CPU mappable GPU memory buffers (aka GMBs) supported or not. do we have any config around this?

Thanks,

 Rp