WebGLRenderingContextBase::commit could have performance issues due to not recycling buffers |
||||||
Issue descriptionWebVR on Windows was experincing issues with RGB backbuffers where ANGLE would spend ~20ms to create a new backbuffer to fill it with initial data. WebGLRenderingContextBase is executing similar code by calling GetStaticBitmapImage. Plumbing was added to return the release callback to recycle textures, but it should be hooked up and tested in WebGLRenderingContextBase::commit.
,
Feb 5 2018
,
Feb 21 2018
I traced the code of DrawingBuffer::TransferToStaticBitmapImage() and came all the way to this issue. This particular function causes two OffscreenCanvas API to result in flaky rendering output as in https://bugs.chromium.org/p/chromium/issues/detail?id=807742 and https://bugs.chromium.org/p/chromium/issues/detail?id=735228. VRDisplay is yet another API that uses this function but it seems to have no problems with this. I find that the major difference is that the function that uses DrawingBuffer::TransferToStaticBitmapImage() in VRDisplay has made use of the release call back in a meaningful way: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/graphics/gpu/XRFrameTransport.h?l=75 I do not know whether this is related to the flakiness. Even if they are not related, I think this is an area that we need to improve for OffscreenCanvas.commit() in webgl rendering context.
,
Apr 13 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4806cee353459fd73ca4c7522701666488e5efc4 commit 4806cee353459fd73ca4c7522701666488e5efc4 Author: xlai <xlai@chromium.org> Date: Fri Apr 13 20:11:13 2018 Add image release callback to Webgl commit() in OffscreenCanvas DrawingBuffer::TransferToStaticBitmapImage() is the common function shared by commit() and transferToImageBitmap() in OffscreenCanvas WebGL, as well as the VR display frame submission. The two OffscreenCanvas APIs miss a release callback; as a result, release_callback populated by image extraction function PrepareTransferableResourceInternal is invoked very early with a "lost resource" signal. On the other hand, VR display frame submission has correctly implemented a release callback that is releasing previous frame whenever there is a new frame coming in. This is a very likely reason to contribute to the flakiness of these two OffscreenCanvas APIs, while the VR display is working well. This CL adds a release callback to OffscreenCanvas commit(). I will follow-up with another CL that adds release callback to OffscreenCanvas transferToImageBitmap() and another CL that enables the relevant gpu pixel tests. Bug: 809227 , 735228 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2;master.tryserver.chromium.win:win_optional_gpu_tests_rel Change-Id: Ia6e2c613de416f1e6e2a0f1c833d9e82e47fed4f Reviewed-on: https://chromium-review.googlesource.com/1010466 Reviewed-by: Justin Novosad <junov@chromium.org> Reviewed-by: Zhenyao Mo <zmo@chromium.org> Commit-Queue: Olivia Lai <xlai@chromium.org> Cr-Commit-Position: refs/heads/master@{#550740} [modify] https://crrev.com/4806cee353459fd73ca4c7522701666488e5efc4/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.cc [modify] https://crrev.com/4806cee353459fd73ca4c7522701666488e5efc4/third_party/blink/renderer/platform/graphics/gpu/drawing_buffer.cc [modify] https://crrev.com/4806cee353459fd73ca4c7522701666488e5efc4/third_party/blink/renderer/platform/graphics/gpu/drawing_buffer.h
,
Apr 17 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4806cee353459fd73ca4c7522701666488e5efc4 commit 4806cee353459fd73ca4c7522701666488e5efc4 Author: xlai <xlai@chromium.org> Date: Fri Apr 13 20:11:13 2018 Add image release callback to Webgl commit() in OffscreenCanvas DrawingBuffer::TransferToStaticBitmapImage() is the common function shared by commit() and transferToImageBitmap() in OffscreenCanvas WebGL, as well as the VR display frame submission. The two OffscreenCanvas APIs miss a release callback; as a result, release_callback populated by image extraction function PrepareTransferableResourceInternal is invoked very early with a "lost resource" signal. On the other hand, VR display frame submission has correctly implemented a release callback that is releasing previous frame whenever there is a new frame coming in. This is a very likely reason to contribute to the flakiness of these two OffscreenCanvas APIs, while the VR display is working well. This CL adds a release callback to OffscreenCanvas commit(). I will follow-up with another CL that adds release callback to OffscreenCanvas transferToImageBitmap() and another CL that enables the relevant gpu pixel tests. Bug: 809227 , 735228 Cq-Include-Trybots: luci.chromium.try:android_optional_gpu_tests_rel;luci.chromium.try:linux_optional_gpu_tests_rel;luci.chromium.try:mac_optional_gpu_tests_rel;master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2;master.tryserver.chromium.win:win_optional_gpu_tests_rel Change-Id: Ia6e2c613de416f1e6e2a0f1c833d9e82e47fed4f Reviewed-on: https://chromium-review.googlesource.com/1010466 Reviewed-by: Justin Novosad <junov@chromium.org> Reviewed-by: Zhenyao Mo <zmo@chromium.org> Commit-Queue: Olivia Lai <xlai@chromium.org> Cr-Commit-Position: refs/heads/master@{#550740} [modify] https://crrev.com/4806cee353459fd73ca4c7522701666488e5efc4/third_party/blink/renderer/modules/webgl/webgl_rendering_context_base.cc [modify] https://crrev.com/4806cee353459fd73ca4c7522701666488e5efc4/third_party/blink/renderer/platform/graphics/gpu/drawing_buffer.cc [modify] https://crrev.com/4806cee353459fd73ca4c7522701666488e5efc4/third_party/blink/renderer/platform/graphics/gpu/drawing_buffer.h
,
Jul 25
,
Jul 27
This got resolved indirectly with the CanvasResource refactoring work. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by billorr@chromium.org
, Feb 5 2018