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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Jan 10 05:41:57 PST 2022


--- Comment #4 from Kimmo Kinnunen <kkinnunen at apple.com> ---
NOTE about the test case measurements:
The test case times are wrong, since the calls might not be completed when the caller side measurement is made.

Consider abstraction of the test case here:
        var s = MEASURE();
        gl.texImage2D(gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, video);
        var upload = MEASURE() - s;

        s = MEASURE();
        gl.drawElements(gl.TRIANGLES, 6, gl.UNSIGNED_SHORT, 0);
        var draw = MEASURE() - s;

        s = MEASURE();
        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);
        var pack = MEASURE() - s;

        s = MEASURE();
        gl.readPixels(0, 0, 640, 360, gl.RGBA, gl.UNSIGNED_BYTE, pixelsDirect);
        var direct = MEASURE() - s;

The first blocking call is getBufferSubData, and as such the duration measurement "pack" might contain delay due to all the work submitted prior to that call.

The second blocking call duration readPixels will contain only the readPixels payload because it comes after a blocking call.

So a benchmark measuring individual gl sequeneces needs to call finish() before taking a measurement start timestamp and end in a blocking call, and needs to take the end timestamp after it.

        var s = MEASURE();
        var dt = MEASURE() - s;

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/20220110/1da144cd/attachment.htm>

More information about the webkit-unassigned mailing list