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

[bugzilla-daemon at webkit.org]

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

            Bug ID: 235002
           Summary: readPixels directly to ArrayBuffer has very high CPU
                    usage
           Product: WebKit
           Version: Safari 15
          Hardware: All
                OS: iOS 15
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: ANGLE
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: simontaylor1 at ntlworld.com
                CC: dino at apple.com, kbr at google.com, kkinnunen at apple.com

WebGL1's readPixels only supports reading directly into an ArrayBuffer, and blocks until the GPU work is completed.

WebGL2 added the ability to target a PIXEL_PACK_BUFFER with readPixels, and then copy the pixels back into an ArrayBuffer with getBufferSubData. The usual recommendation is to insert a fence after the readPixels, and wait until it is signalled before calling getBufferSubData which will prevent the main thread blocking on GPU completion.

My expectation was that there would be no performance benefit to using a PIXEL_PACK_BUFFER with immediate readback, where getBufferSubData will also block until GPU completion.

i.e. I expected the webgl2-only:

gl.bindBuffer(gl.PIXEL_PACK_BUFFER, pixelBuffer);
gl.readPixels(0, 0, 640, 360, gl.RGBA, gl.UNSIGNED_BYTE, 0);
gl.getBufferSubData(gl.PIXEL_PACK_BUFFER, 0, pixels);

to have no major performance advantage over the equivalent direct route:

gl.bindBuffer(gl.PIXEL_PACK_BUFFER, null);
gl.readPixels(0, 0, 640, 360, gl.RGBA, gl.UNSIGNED_BYTE, pixels);

However on both iOS (tested on 15.2) and macOS (12.1, Safari 15.2) the direct option is many times slower, and looking at a System Trace in Instruments involves way more CPU activity long after the GPU has finished.

Test case coming up next, along with some System Trace findings from Instruments.

-- 
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/77193ae9/attachment-0001.htm>