[Webkit-unassigned] [Bug 235002] readPixels directly to ArrayBuffer has very high CPU usage

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=235002

--- Comment #2 from Simon Taylor <simontaylor1 at ntlworld.com> ---
Created attachment 448667

  --> https://bugs.webkit.org/attachment.cgi?id=448667&action=review

Annotated System Trace for a frame of the demo content

I've attached an annotated System Trace screenshot for one frame of this demo.

The flags in the timeline show the console.log calls at different checkpoints (when WebInspector is open these result in syscalls, so can be accurately located on the trace). The full set of 8 logs are:
  start
  upload complete
  draw complete
  readPixels (via buffer) complete
  getBufferSubData complete
  readPixels (direct) complete
  texImage from ArrayBuffer complete
  second draw complete

The three annotated regions dominate the timings:
 1. texImage2d from video element (this is a frame where the video has a new frame, so is the heavier workload)
 2. getSubImageData - note the vast majority of this time is blocking waiting for GPU (syscall stack shows it is within [_MTLCommandBuffer waitUntilCompleted]), and the CPU is essentially idle for this time.
 3. readPixels directly to ArrayBuffer - note CPU is pegged throughout.

During the slow readPixels you can see loads of syscalls going on, looks like repeated calls to IOSurfaceClientLock and IOSurfaceClientUnlock. The relevant bit of the stack from one of these is shown below. I wonder if this is some "robust" fallback path (ReadnPixelsRobustANGLE is in the trace) that perhaps individually fetches one row at a time?

It feels like there's very significant gains to be made here by switching to a similar backend implementation of the PIXEL_PACK_BUFFER readback.

   0 libsystem_kernel.dylib mach_msg_trap
   1 IOKit io_connect_method
   2 IOKit IOConnectCallMethod
   3 IOSurface IOSurfaceClientLock
   4 AGXMetalA14 0x1f3082ee4
   5 AGXMetalA14 0x1f3082e80
   6 libANGLE-shared.dylib rx::mtl::Texture::getBytes(rx::ContextMtl*, unsigned long, unsigned long, MTLRegion const&, gl::LevelIndexWrapper<unsigned int> const&, unsigned int, unsigned char*)
   7 libANGLE-shared.dylib rx::mtl::ReadTexturePerSliceBytes(gl::Context const*, std::__1::shared_ptr<rx::mtl::Texture> const&, unsigned long, gl::Rectangle const&, gl::LevelIndexWrapper<unsigned int> const&, unsigned int, unsigned char*)
   8 libANGLE-shared.dylib rx::FramebufferMtl::readPixelsImpl(gl::Context const*, gl::Rectangle const&, rx::PackPixelsParams const&, rx::RenderTargetMtl const*, unsigned char*) const
   9 libANGLE-shared.dylib rx::FramebufferMtl::readPixels(gl::Context const*, gl::Rectangle const&, unsigned int, unsigned int, gl::PixelPackState const&, gl::Buffer*, void*)
  10 libANGLE-shared.dylib gl::Framebuffer::readPixels(gl::Context const*, gl::Rectangle const&, unsigned int, unsigned int, gl::PixelPackState const&, gl::Buffer*, void*)
  11 libANGLE-shared.dylib gl::Context::readPixels(int, int, int, int, unsigned int, unsigned int, void*)
  12 libANGLE-shared.dylib gl::ReadnPixelsRobustANGLE(int, int, int, int, unsigned int, unsigned int, int, int*, int*, int*, void*)
  13 WebCore WebCore::GraphicsContextGLOpenGL::readnPixelsImpl(int, int, int, int, unsigned int, unsigned int, int, int*, int*, int*, void*, bool)
  14 WebCore WebCore::GraphicsContextGLOpenGL::readnPixels(int, int, int, int, unsigned int, unsigned int, GCGLSpan<void, 18446744073709551615ul>)
  15 WebCore WebCore::WebGLRenderingContextBase::readPixels(int, int, int, int, unsigned int, unsigned int, JSC::ArrayBufferView&)
  16 WebCore WebCore::jsWebGL2RenderingContextPrototypeFunction_readPixels(JSC::JSGlobalObject*, JSC::CallFrame*)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220108/b255d30d/attachment-0001.htm>