Texture upload performance with Angle

[kvark]

Bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1478125

We spend significant amount of time uploading data with Angle. Note that this wasn't fixed or affected in any way by #2950 because we don't use PBO upload path on Angle, since D3D11 doesn't know how to copy between textures and buffers.

[kvark]

Spent some time looking at this. Angle logic if fairly optimal:

• they create a staging texture of the same dimensions
• they map it and fill it with user-provided contents
  • filling works best when the rows are aligned to 256 bytes (presumably matching D3D12_TEXTURE_DATA_PITCH_ALIGNMENT, but I wasn't able to find it for D3D11).
• then Angle issues a CopySubresourceRegion to sync the staging texture back with the GPU local version
• it tries to keep the staging texture around if it's used consistently, however redefining the texture contents (even with exactly the same values) forces it to recreate both staging and device local textures.

From this, my recommendation would be to:

1. make sure Gecko uses an alignment of 256 bytes for (larger) external images
2. minimize the image re-definition, if possible

cc @jrmuizel @nical

[kvark]

Thinking about this some more, I'm afraid there is no single code path for us to follow that would translate to efficient use of hardware on both GL and DX11 :(

On GL, texture uploads (and data uploads in general) are meant to go via PBO, and that's what we are currently doing. However, on Angle we disable this and go straight for glTexSubImage2D, since Angle doesn't work well with PBO-based texture uploads. Most importantly, DX11 is simply lacking the buffer -> texture copy operation.

With this in mind, the best path for DX11 would be to allocate a large scratch space (say 2K by 2K) that is mapped, filled, and copied from into the target texture. However, there is no ability for us to make Angle do this.

Another (radical) alternative would be for DX11 to copy from buffer to texture using a compute shader. This would map directly to our PBO-based uploads, and this is what gfx-rs DX11 backend is doing now. I don't think we want to implement this copy path directly now, but it's good to know that we are going to get that best path when/if we eventually switch to gfx-rs. Not to mention that DX12/Metal/Vulkan also map nicely to PBO-based uploads since they support buffer-texture copies natively.

[nical]

Have we measured the performance of the compute shader approach? I really like the idea a lot but it's hard to predict the performance characteristics of these things.
We can also look into implementing texture uploads directly with D3D11 and bypass ANGLE if there's significant wins to be had. Texture uploads are enough of a bottleneck that we shouldn't compromise too much.

[kvark]

Have we measured the performance of the compute shader approach? I really like the idea a lot but it's hard to predict the performance characteristics of these things.

We haven't benchmarked it against texture-texture copies. It was implemented for buffer-texture copies in DX11 that have no alternative to benchmark against :)

We can also look into implementing texture uploads directly with D3D11 and bypass ANGLE if there's significant wins to be had.

Where is this implementation supposed to live?

I'm also thinking that we may be able to address it on Gecko's side. Say, Gecko could align the texture sizes for blobs to some value, e.g. 16. Gecko could keep using the same texture if the script needs a smaller size. This will keep it the same handle on WR side, would help us to avoid the scene rebuild, and would make Angle to keep the staging texture around. Wins everywhere!

[kvark]

Also, cc @fkaa who got the compute path implemented in our dx11 backend.

[jrmuizel]

There's also https://chromium.googlesource.com/angle/angle/+/master/extensions/EGL_ANGLE_d3d_texture_client_buffer.txt

[sotaroikeda]

There's also https://chromium.googlesource.com/angle/angle/+/master/extensions/EGL_ANGLE_d3d_texture_client_buffer.txt

RenderDXGITextureHostOGL uses ANGLE_stream_producer_d3d_texture

https://dxr.mozilla.org/mozilla-central/source/gfx/webrender_bindings/RenderD3D11TextureHostOGL.cpp#64

https://chromium.googlesource.com/angle/angle/+/master/extensions/EGL_ANGLE_d3d_texture_client_buffer.txt

[nical]

Where is this implementation supposed to live?

That's really a detail if we are bottlenecked on texture uploads (which we tend to be). Off hands I'd say expose a handler to let gecko perform the texture upload since the D3D device is accessible from gecko's side.
If there is another way that performs as well I'm all for it but let's make sure we go for the most performant solution.

[kvark]

That's really a detail if we are bottlenecked on texture uploads (which we tend to be)

Yes, I was curious on how you think this detail should be addressed.

expose a handler to let gecko perform the texture upload since the D3D device is accessible from gecko's side

Can it just use the existing external texture path of WR instead of adding yet another handler? I.e. WR sees it as a GL texture, and Gecko does all the extension magic of mapping it to D3D11 and uploads as it pleases.

Also, without going into D3D11-GL interop, can Gecko keep the blob contents upon resize to avoid re-defining WR texture (and instead just re-define the image UV)? This would mean Angle doesn't go the slow path, and WR can potentially do less scene building.

[nical]

Can it just use the existing external texture path of WR instead of adding yet another handler? I.e. WR sees it as a GL texture, and Gecko does all the extension magic of mapping it to D3D11 and uploads as it pleases.

Probably if we change the way blob images work. Right now the blob image rasterizer produces CPU-side images that are passed to WebRender right away and wr takes care of bundling that in the transaction, sending to the proper threads and lazily do the uploads.
I suppose we could try to instead have the blob rasterizer produce external image handles and send the data to the renderer thread so that they go through the external image path. Doing that means we need to figure out the life cylce of these images which isn't straightforward. I'm not sure it'd be a win over adding another hook, but it's something to think about.

Also, without going into D3D11-GL interop, can Gecko keep the blob contents upon resize to avoid re-defining WR texture (and instead just re-define the image UV)? This would mean Angle doesn't go the slow path, and WR can potentially do less scene building.

I don't know the code that builds up the blob recordings well enough (it's most of the code in WebRenderCommandBuilder.cpp if you are interested), @jrmuizel, @mstange or @gankro would know better.
It sounds reasonable to round up the extents to a multiple of the ideal stride and allow resizing within these bounds while keeping the image key. It would probably help a great deal on some animations like the one at the bottom the digitalocean website.