Fixed
Status Update
No update yet.
Comments
er...@spiideo.com
Adding a screenshot from chrome developer tools performance tab
da...@chromium.org
[Empty comment from Monorail migration]
[Monorail components: Blink>WebGL]
[Monorail components: Blink>WebGL]
sa...@chromium.org
[Empty comment from Monorail migration]
sw...@chromium.org
The issue seems similar to issue id: 1002913, CC'ing "enga" from the issue and requesting to look into it, help further.
Thanks.!
Thanks.!
sh...@google.com
Running a bisect. Yet the video doesn't load and play properly in chromium build downloaded. (DOMException, "Failed to load because no supported source was found", even if video.play after user input). Runs in regular chrome. Trying to figure out the reason. Post to see if someone knows what's possibly wrong.
sh...@google.com
[Empty comment from Monorail migration]
sw...@chromium.org
Tried testing the issue on reported chrome version #77.0.3865.90 using Mac OS 10.13.6 by following below steps.
Steps:
=====
1.Navigated to "https://bes.github.io/chrome-video-texture-upload-slow/index.html ".
2.Opened Devtools>Performance tab.
3.Recorded the session and observed that all tasks took time lesser than 200ms.
Attached screenshot and screenshot for reference.
@reporter: Could you please review attached screencast and screenshot and let us know if anything is missed from our end.
Thanks.!
Steps:
=====
1.Navigated to "
2.Opened Devtools>Performance tab.
3.Recorded the session and observed that all tasks took time lesser than 200ms.
Attached screenshot and screenshot for reference.
@reporter: Could you please review attached screencast and screenshot and let us know if anything is missed from our end.
Thanks.!
sh...@google.com
Thanks for taking this. Not sure if it's because I'm not under google network. Chromium downloaded bisect script couldn't load video properly on my end for now.
er...@spiideo.com
Thanks swarnasree and shrekshao, yes the video shows what I am seeing. Chrome 77 has very long texImage2D time.
er...@spiideo.com
Less than 200ms is still not OK, it should take less than 16ms?!
er...@spiideo.com
As it does on Chrome 76.
er...@spiideo.com
Please compare with Chrome 76, latest Safari or latest Firefox, there it works perfectly.
du...@gmail.com
I can also reproduce this regression on my production WebGL video app. Try this JSFiddle in Chrome 76 vs 77 and note the massive difference in upload times - https://jsfiddle.net/qz9ka6xm
sh...@google.com
Austin can you try running a bisect on this? Thanks! (Left my Mac at home)
sh...@google.com
[Empty comment from Monorail migration]
sh...@google.com
Ran a bisect, regression introduced in https://chromium.googlesource.com/chromium/src/+log/a02ac85b0aa0a63e087ef58dad3d4d435587708a..93f4ddb172007cb52332735b5e19f1e6656ce3d8
https://chromium-review.googlesource.com/c/chromium/src/+/1616978
The original CL is by Antoine who has left chrome. Assigned to reviewer. Feel free to reassign if necessary
The original CL is by Antoine who has left chrome. Assigned to reviewer. Feel free to reassign if necessary
kb...@chromium.org
+khushalsagar are you familiar with the SharedImage path for uploading videos and could you offer any help to diagnose this regression?
[Monorail components: Internals>GPU>Video]
[Monorail components: Internals>GPU>Video]
du...@gmail.com
I just wanted to voice the importance of WebGL video support in Chrome - all 360 video players are affected by this regression including YouTube. Please let me know if I can help debug.
sa...@chromium.org
Does the issue reproduce in Canary? There have been more changes to the SharedImage code since that CL, there may already be something we should have merged back.
du...@gmail.com
Today's Canary does not seem to be affected by this regression. Would it be possible to hotfix 77.x with the new code?
sa...@chromium.org
There are enough changes (https://chromium.googlesource.com/chromium/src/+log/HEAD/media/renderers/paint_canvas_video_renderer.cc ) that it's not trivial, but it's clearly worth investigating.
I suspect it might behttps://chromium.googlesource.com/chromium/src/+/bec0951d6fa63bec0a49352af7f7d1bb9e24f111 . I'll see if I can reproduce on my hardware.
I suspect it might be
kh...@chromium.org
Can you share a chrome trace for rendering categories? That would help a lot in debugging this. Here are the instructions for capturing a trace : https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs
kh...@chromium.org
I don't see any of the relevant categories in the trace. When you hit "Record", did you select the "rendering" option before recording? There should be a greyed out list of included categories in that option : "benchmark,blink,cc,gpu,toplevel,viz".
du...@gmail.com
Sorry about that. I had manually selected "renderer" rather than the "Rendering" checkbox. Here is a new trace. Let me know if it's missing anything.
du...@gmail.com
Also, note that in this trace, you will likely see portions that aren't actively decoding video. That's due to the ad-hoc decoding nature of PanoMoments, where it's only decoding when the user is interacting.
du...@gmail.com
Some additional channel testing:
Chrome 77 Stable - Regression
Chrome Beta - Regression
Chrome Dev - Fixed
Chrome Canary - Fixed
Chrome 77 Stable - Regression
Chrome Beta - Regression
Chrome Dev - Fixed
Chrome Canary - Fixed
kh...@chromium.org
Thanks for the trace! Every instance that's slow looks like a readback but I couldn't figure out from the trace what's causing the readback. Since you said this is fixed on canary, the fix could likely be : https://chromium-review.googlesource.com/c/chromium/src/+/1815734 .
du...@gmail.com
Great, is that fix also in Chrome Dev?
du...@gmail.com
Ok, yah. It's definitely fixed in the Chrome Dev channel - Version 79.0.3921.0 (Official Build) dev (64-bit), so it seems like it could be something else.
du...@gmail.com
[Comment Deleted]
du...@gmail.com
Please ignore my deleted comment (in case you received the email notification) - This issue does appear to be resolved fully in Chrome Dev in addition to Chrome Canary.
sa...@chromium.org
[Comment Deleted]
sa...@chromium.org
I was unable to isolate the fix to a CL affecting PaintCanvasVideoRenderer.
Specifically, I found commit bec0951d6fa6 (Avoid memcpy) to be good and 8af6f946389b (Deprecate PIXEL_FORMAT_UYVY) to be bad, but between them is an unrelated commit 6b2e17f01cc1 (parent of bec0951d6fa6) which was also good.
The actual fix may have been a Skia roll, but there are many of these in the suspected range.
Specifically, I found commit bec0951d6fa6 (Avoid memcpy) to be good and 8af6f946389b (Deprecate PIXEL_FORMAT_UYVY) to be bad, but between them is an unrelated commit 6b2e17f01cc1 (parent of bec0951d6fa6) which was also good.
The actual fix may have been a Skia roll, but there are many of these in the suspected range.
sa...@chromium.org
Any ideas who in Skia we can rope into this one?
[Monorail components: Internals>Skia]
[Monorail components: Internals>Skia]
kb...@chromium.org
Maybe +bsalomon.
bs...@google.com
I can reproduce the issue at 8af6f946389b and not at bec0951d6fa6. Going to see if I can bisect it.
bs...@google.com
[Comment Deleted]
bs...@google.com
This was fixed by Khushal's change in this roll:
https://chromium.googlesource.com/chromium/src/+/324f873b499834b1c1590ea8e13bee617eb1ffcd
However, landing that change in Skia required some Chrome changes, so over to Khushal to evaluate what to do.
However, landing that change in Skia required some Chrome changes, so over to Khushal to evaluate what to do.
kh...@chromium.org
I'll try to repro locally to see what aspect of this change fixed it.
kh...@chromium.org
The bug boils down to the change in behaviour here : https://chromium-review.googlesource.com/c/chromium/src/+/1616978/16/media/renderers/paint_canvas_video_renderer.cc#b312 . When wrapping video frame textures to SkImages we always used GL_TEXTURE_2D as the format while it could be GL_TEXTURE_RECTANGLE_ARB or GL_TEXTURE_EXTERNAL_OES. After that change, we pass the actual format to skia and skia didn't support GL_TEXTURE_RECTANGLE_ARB we were falling back to software mode for video draw causing a readback of the video frame.
The skia change mentioned in #40 fixed it because now skia supports GL_TEXTURE_RECTANGLE_ARB. Merging this to 78 is not an option because a bunch of dependent chromium changes also had to land to make it work. The simplest fix is to restore the behaviour before piman's change and pretend that the format is GL_TEXTURE_2D. kbr/bsalomon, Is that behaviour correct though?
The skia change mentioned in #40 fixed it because now skia supports GL_TEXTURE_RECTANGLE_ARB. Merging this to 78 is not an option because a bunch of dependent chromium changes also had to land to make it work. The simplest fix is to restore the behaviour before piman's change and pretend that the format is GL_TEXTURE_2D. kbr/bsalomon, Is that behaviour correct though?
kb...@chromium.org
It's not clear to me which of the old two code paths (wrap_texture or not) in NewSkImageFromVideoFrameNative used to be taken - but the texture targets GL_TEXTURE_RECTANGLE_ARB, GL_TEXTURE_2D and GL_TEXTURE_EXTERNAL_OES are not compatible. In the "else" branch of the old code's "if (wrap_texture)", glCopyTextureCHROMIUM handled the differences between the kinds of source textures, and always did a GPU-GPU copy of the frame_texture into source_texture, creating a GL_TEXTURE_2D type texture as a result.
I'm not sure what's being considered for M78 - revertinghttps://chromium-review.googlesource.com/1616978 on the branch? If that can be done cleanly, and the M78 branch can be built and some manual testing done to ensure that the video-related WebGL conformance tests all pass and that the performance regression is fixed, that sounds OK. Other changes like simply treating GL_TEXTURE_RECTANGLE_ARB as GL_TEXTURE_2D won't work.
Ideally we'll add a video-to-WebGL performance test as a consequence of this bug. One can be added here:
https://cs.chromium.org/chromium/src/tools/perf/page_sets/rendering/tough_webgl_cases.py?q=tough_webgl_cases&sq=package:chromium&g=0&l=1
and the associated rendering page set re-recorded.
Thanks Khushal for picking this up.
I'm not sure what's being considered for M78 - reverting
Ideally we'll add a video-to-WebGL performance test as a consequence of this bug. One can be added here:
and the associated rendering page set re-recorded.
Thanks Khushal for picking this up.
kh...@chromium.org
Thanks for clarifying!
The code path we're hitting for for the WebGL copy here is CopyVideoTextureToPlatformTexture which hits the wrap_texture = true branch from the UpdateLastImage call here :https://chromium-review.googlesource.com/c/chromium/src/+/1616978/16/media/renderers/paint_canvas_video_renderer.cc#b1101 and it was working earlier because of the bug with passing an incorrect format to skia for that texture.
I was actually suggesting treating GL_TEXTURE_RECTANGLE_ARB as GL_TEXTURE_2D as a "fix" for 78, seemed like a less risky thing since it reverts back to the old behaviour prior to the patch. But reverting the complete patch if its a clean revert definitely sounds better. In case that doesn't work, another option would be to force a GPU-GPU copy for this case depending on the video texture format.
The code path we're hitting for for the WebGL copy here is CopyVideoTextureToPlatformTexture which hits the wrap_texture = true branch from the UpdateLastImage call here :
I was actually suggesting treating GL_TEXTURE_RECTANGLE_ARB as GL_TEXTURE_2D as a "fix" for 78, seemed like a less risky thing since it reverts back to the old behaviour prior to the patch. But reverting the complete patch if its a clean revert definitely sounds better. In case that doesn't work, another option would be to force a GPU-GPU copy for this case depending on the video texture format.
kh...@chromium.org
Adding some labels to remember to get a scoped fix in for 78.
kb...@chromium.org
Thanks for the explanation - I'm a little surprised that worked, but honestly anything that gets M78 working, and faster, sounds good to me.
kb...@chromium.org
[Empty comment from Monorail migration]
du...@gmail.com
Glad to hear there was a simple workaround/fix. Do you think it could make sense to also hotfix this on 77.x?
kh...@chromium.org
I don't think we'll be able to get the fix in for 77, its too late in the cycle. cc-ing the TPMs. Maybe we can cherry-pick the revert to 77 if there is going to be a respin.
kb...@chromium.org
#48, submitter: please also test routinely with Chrome Beta (if not also Chrome Canary) and report any problems you see as early as possible. Feel free to email me directly any bug IDs related to WebGL issues. The earlier we hear about problems like this, the better.
We do extensive correctness testing of WebGL to ensure no regressions; this particular area is a gap in our performance testing.
We do extensive correctness testing of WebGL to ensure no regressions; this particular area is a gap in our performance testing.
kh...@chromium.org
One potential workaround I could see for this is using a 2d canvas to draw the video and creating the WebGL texture using this canvas as a source. It'll avoid the readback and re-upload which is the main source of the slowness here. The video frame will be copied on the GPU (twice I think, sigh) but should still be faster than the current mode.
kh...@chromium.org
[Empty comment from Monorail migration]
kh...@chromium.org
The offending patch needs to be reverted on the m78 branch : https://chromium-review.googlesource.com/c/chromium/src/+/1850582 . Raising a merge request for that. I've verified locally that reverting the change fixes the issue but will do some sanity testing before merging.
sh...@chromium.org
This bug requires manual review: We are only 12 days from stable.
Before a merge request will be considered, the following information is required to be added to this bug:
1. Does your merge fit within the Merge Decision Guidelines?
- Chrome:https://goto.google.com/chrome-release-branch-merge-guidelines
- Chrome OS:https://goto.google.com/cros-release-branch-merge-guidelines
2. Links to the CLs you are requesting to merge.
3. Has the change landed and been verified on master/ToT?
4. Why are these changes required in this milestone after branch?
5. Is this a new feature?
6. If it is a new feature, is it behind a flag using finch?
Please contact the milestone owner if you have questions.
Owners: govind@(Android), kariahda@(iOS), geohsu@(ChromeOS), srinivassista@(Desktop)
For more details visithttps://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Before a merge request will be considered, the following information is required to be added to this bug:
1. Does your merge fit within the Merge Decision Guidelines?
- Chrome:
- Chrome OS:
2. Links to the CLs you are requesting to merge.
3. Has the change landed and been verified on master/ToT?
4. Why are these changes required in this milestone after branch?
5. Is this a new feature?
6. If it is a new feature, is it behind a flag using finch?
Please contact the milestone owner if you have questions.
Owners: govind@(Android), kariahda@(iOS), geohsu@(ChromeOS), srinivassista@(Desktop)
For more details visit
sr...@google.com
lets wait for the patch to land and verified in canary for merge approval
kh...@chromium.org
I'm reverting the change directly on 78 branch. Reverting it on tot is tricky because a lot more changes have landed on top of it and also not necessary because the bug is already fixed on tot (for m79). The revert is the least risky fix for m78.
sr...@google.com
thanks Kushalsagar@ approving the merge to M78, branch:3904
sr...@google.com
Please help complete the merge to M78 branch by End of day Friday Oct 11, 2019, PST time zone. Stable RC build will be triggered early next week
bu...@chops-service-accounts.iam.gserviceaccount.com
The following revision refers to this bug:
https://chromium.googlesource.com/chromium/src.git/+/f406a8ca570d0030ecdd28600e38d0ac0b80a640
commit f406a8ca570d0030ecdd28600e38d0ac0b80a640
Author: Khushal Sagar <khushalsagar@chromium.org>
Date: Thu Oct 10 18:44:10 2019
Revert "Migrate PaintCanvasVideoRenderer to shared images"
This reverts commit 93f4ddb172007cb52332735b5e19f1e6656ce3d8. The change
inadvertantly disabled copying video frames on the GPU for mac resulting
in fallback to software mode. This does a readback and reupload of the
video frame which is extremely slow.
R=kbr@chromium.org
Bug: 1007889
Change-Id: I136de6e5e295d97932cc130574f29a479b53687d
Reviewed-on:https://chromium-review.googlesource.com/c/chromium/src/+/1850582
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/branch-heads/3904@{#714}
Cr-Branched-From: 675968a8c657a3bd9c1c2c20c5d2935577bbc5e6-refs/heads/master@{#693954}
[modify]https://crrev.com/f406a8ca570d0030ecdd28600e38d0ac0b80a640/media/renderers/paint_canvas_video_renderer.cc
[modify]https://crrev.com/f406a8ca570d0030ecdd28600e38d0ac0b80a640/media/renderers/paint_canvas_video_renderer.h
commit f406a8ca570d0030ecdd28600e38d0ac0b80a640
Author: Khushal Sagar <khushalsagar@chromium.org>
Date: Thu Oct 10 18:44:10 2019
Revert "Migrate PaintCanvasVideoRenderer to shared images"
This reverts commit 93f4ddb172007cb52332735b5e19f1e6656ce3d8. The change
inadvertantly disabled copying video frames on the GPU for mac resulting
in fallback to software mode. This does a readback and reupload of the
video frame which is extremely slow.
R=kbr@chromium.org
Bug: 1007889
Change-Id: I136de6e5e295d97932cc130574f29a479b53687d
Reviewed-on:
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Cr-Commit-Position: refs/branch-heads/3904@{#714}
Cr-Branched-From: 675968a8c657a3bd9c1c2c20c5d2935577bbc5e6-refs/heads/master@{#693954}
[modify]
[modify]
sa...@chromium.org
[Empty comment from Monorail migration]
[Deleted User] <[Deleted User]>
jo...@aetheres.com.c-02jhvuoq.appstempdomain.goog
After focusing elsewhere we came back to chrome and found this issue. Whew! Glad its found and fixed! Thank you all!
Whats the ETA to the main branch?
Whats the ETA to the main branch?
du...@gmail.com
Has this been checked into the Chrome Beta branch? I was just interested in giving it a spin.
sr...@google.com
It will be part of this week's beta release, tentatively scheduled for this wednesday.
sw...@chromium.org
Able to reproduce the issue on reported chrome version #77.0.3865.90 using Mac OS 10.13.6 by following steps as per https://crbug.com/chromium/1007889#c13 .
Note: In the reported version the FPS is 17.8000 for 23.98 ms in 1080p, FPS 7.4 for 88.60 in 2160p.
Verified the fix on Mac 10.13.6 as perhttps://crbug.com/chromium/1007889#c13 on latest chrome version #78.0.3904.63.
Attaching screenshot for reference.
Observed that the frame per second rate is faster.
Hence, the fix is working as expected.
Adding the verified labels.
Thanks...!!
Note: In the reported version the FPS is 17.8000 for 23.98 ms in 1080p, FPS 7.4 for 88.60 in 2160p.
Verified the fix on Mac 10.13.6 as per
Attaching screenshot for reference.
Observed that the frame per second rate is faster.
Hence, the fix is working as expected.
Adding the verified labels.
Thanks...!!
ha...@google.com
[Empty comment from Monorail migration]
is...@google.com
This issue was migrated from crbug.com/chromium/1007889?no_tracker_redirect=1
[Auto-CCs applied]
[Multiple monorail components: Blink>WebGL, Internals>GPU>Video, Internals>Media, Internals>Skia]
[Monorail blocking:crbug.com/chromium/1012810 ]
[Monorail components added to Component Tags custom field.]
[Auto-CCs applied]
[Multiple monorail components: Blink>WebGL, Internals>GPU>Video, Internals>Media, Internals>Skia]
[Monorail blocking:
[Monorail components added to Component Tags custom field.]
Description
Example URL:
Steps to reproduce the problem:
1. Go to
2. Use performance tab in Chrome and record for a few seconds
3. See that texImage2D takes over 200ms per frame
What is the expected behavior?
The expected behavior is that it should work like on Chrome 76, i.e. faster than 16ms, not slower than 200ms.
It works perfectly on Chrome 76, Safari 12, Firefox 69.
What went wrong?
It takes a very long time to upload video textures using texImage2D on Chrome 77.
Did this work before? Yes Chrome 76
Is it a problem with Flash or HTML5? HTML5
Does this work in other browsers? Yes
Chrome version: 77.0.3865.90 Channel: stable
OS Version: OS X 10.14.6
Flash Version:
Contents of chrome://gpu:
Graphics Feature Status
Canvas: Hardware accelerated
Flash: Hardware accelerated
Flash Stage3D: Hardware accelerated
Flash Stage3D Baseline profile: Hardware accelerated
Compositing: Hardware accelerated
Metal: Disabled
Multiple Raster Threads: Enabled
Out-of-process Rasterization: Disabled
Hardware Protected Video Decode: Unavailable
Rasterization: Hardware accelerated
Skia Renderer: Disabled
Video Decode: Hardware accelerated
Viz Display Compositor: Enabled
Viz Hit-test Surface Layer: Disabled
WebGL: Hardware accelerated
WebGL2: Hardware accelerated
Driver Bug Workarounds
add_and_true_to_loop_condition
adjust_src_dst_region_for_blitframebuffer
avoid_stencil_buffers
clamp_texture_base_level_and_max_level
decode_encode_srgb_for_generatemipmap
disable_2d_canvas_auto_flush
disable_webgl_rgb_multisampling_usage
dont_use_loops_to_initialize_variables
emulate_abs_int_function
get_frag_data_info_bug
init_two_cube_map_levels_before_copyteximage
max_msaa_sample_count_4
msaa_is_slow
pack_parameters_workaround_with_pack_buffer
rebind_transform_feedback_before_resume
regenerate_struct_names
remove_invariant_and_centroid_for_essl3
reset_teximage2d_base_level
rewrite_texelfetchoffset_to_texelfetch
scalarize_vec_and_mat_constructor_args
set_zero_level_before_generating_mipmap
unfold_short_circuit_as_ternary_operation
unpack_alignment_workaround_with_unpack_buffer
unpack_image_height_workaround_with_unpack_buffer
use_intermediary_for_copy_texture_image
use_unused_standard_shared_blocks
disabled_extension_GL_KHR_blend_equation_advanced
disabled_extension_GL_KHR_blend_equation_advanced_coherent
Problems Detected
Protected video decoding with swap chain is for Windows and Intel only
Disabled Features: protected_video_decode
Unfold short circuit on Mac OS X: 307751
Applied Workarounds: unfold_short_circuit_as_ternary_operation
Always rewrite vec/mat constructors to be consistent: 398694
Applied Workarounds: scalarize_vec_and_mat_constructor_args
Mac drivers handle struct scopes incorrectly: 403957
Applied Workarounds: regenerate_struct_names
On Intel GPUs MSAA performance is not acceptable for GPU rasterization: 527565
Applied Workarounds: msaa_is_slow
glGenerateMipmap fails if the zero texture level is not set on some Mac drivers: 560499
Applied Workarounds: set_zero_level_before_generating_mipmap
Pack parameters work incorrectly with pack buffer bound: 563714
Applied Workarounds: pack_parameters_workaround_with_pack_buffer
Alignment works incorrectly with unpack buffer bound: 563714
Applied Workarounds: unpack_alignment_workaround_with_unpack_buffer
copyTexImage2D fails when reading from IOSurface on multiple GPU types.: 581777
Applied Workarounds: use_intermediary_for_copy_texture_image
Multisample renderbuffers with format GL_RGB8 have performance issues on Intel GPUs.: 607130
Applied Workarounds: disable_webgl_rgb_multisampling_usage
glGetFragData{Location|Index} works incorrectly on Max: 638340
Applied Workarounds: get_frag_data_info_bug
glResumeTransformFeedback works incorrectly on Intel GPUs: 638514
Applied Workarounds: rebind_transform_feedback_before_resume
Result of abs(i) where i is an integer in vertex shader is wrong: 642227
Applied Workarounds: emulate_abs_int_function
Rewrite texelFetchOffset to texelFetch for Intel Mac: 642605
Applied Workarounds: rewrite_texelfetchoffset_to_texelfetch
Rewrite condition in for and while loops for Intel Mac: 644669
Applied Workarounds: add_and_true_to_loop_condition
Decode and encode before generateMipmap for srgb format textures on macosx: 634519
Applied Workarounds: decode_encode_srgb_for_generatemipmap
Init first two levels before CopyTexImage2D for cube map texture on Intel Mac 10.12: 648197
Applied Workarounds: init_two_cube_map_levels_before_copyteximage
Insert statements to reference all members in unused std140/shared blocks on Mac: 618464
Applied Workarounds: use_unused_standard_shared_blocks
Tex(Sub)Image3D performs incorrectly when uploading from unpack buffer with GL_UNPACK_IMAGE_HEIGHT greater than zero on Intel Macs: 654258
Applied Workarounds: unpack_image_height_workaround_with_unpack_buffer
adjust src/dst region if blitting pixels outside framebuffer on Mac: 644740
Applied Workarounds: adjust_src_dst_region_for_blitframebuffer
Mac driver GL 4.1 requires invariant and centroid to match between shaders: 639760, 641129
Applied Workarounds: remove_invariant_and_centroid_for_essl3
Disable KHR_blend_equation_advanced until cc shaders are updated: 661715
Applied Workarounds: disable(GL_KHR_blend_equation_advanced), disable(GL_KHR_blend_equation_advanced_coherent)
Certain Apple devices leak stencil buffers: 713854
Applied Workarounds: avoid_stencil_buffers
Reset TexImage2D base level to 0 on Intel Mac 10.12.4: 705865
Applied Workarounds: reset_teximage2d_base_level
Shader variable initialization in a loop caused perf regression on Mac Intel.: 809422
Applied Workarounds: dont_use_loops_to_initialize_variables
8x MSAA is slow for alpha:false WebGL contexts on Mac Intel: 812071
Applied Workarounds: max_msaa_sample_count_4
glFlush error on Mac: 841755
Applied Workarounds: disable_2d_canvas_auto_flush
Clamp texture's BASE_LEVEL/MAX_LEVEL for GenerateMipmap: 913301
Applied Workarounds: clamp_texture_base_level_and_max_level
Version Information
Data exported 2019-09-25T07:58:58.887Z
Chrome version Chrome/77.0.3865.90
Operating system Mac OS X 10.14.6
Software rendering list URL
Driver bug list URL
ANGLE commit id 7cf862c9fcd2
2D graphics backend Skia/77 a10014304cba4f24b7af17191f59490faa8aee77
Command Line /Applications/Google Chrome.app/Contents/MacOS/Google Chrome --flag-switches-begin --flag-switches-end
Driver Information
Initialization time 63
In-process GPU false
Passthrough Command Decoder false
Sandboxed true
GPU0 VENDOR = 0x8086 [Intel Inc.], DEVICE= 0x0d26 [Intel Iris Pro OpenGL Engine] *ACTIVE*
Optimus false
AMD switchable false
Driver vendor INTEL
Driver version 12.10.12
Driver date
GPU CUDA compute capability major version 0
Pixel shader version 4.10
Vertex shader version 4.10
Max. MSAA samples 8
Machine model name MacBookPro
Machine model version 11.4
GL_VENDOR Intel Inc.
GL_RENDERER Intel Iris Pro OpenGL Engine
GL_VERSION 4.1 INTEL-12.10.12
GL_EXTENSIONS GL_ARB_blend_func_extended GL_ARB_draw_buffers_blend GL_ARB_draw_indirect GL_ARB_ES2_compatibility GL_ARB_explicit_attrib_location GL_ARB_gpu_shader_fp64 GL_ARB_gpu_shader5 GL_ARB_instanced_arrays GL_ARB_internalformat_query GL_ARB_occlusion_query2 GL_ARB_sample_shading GL_ARB_sampler_objects GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding GL_ARB_shader_subroutine GL_ARB_shading_language_include GL_ARB_tessellation_shader GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_cube_map_array GL_ARB_texture_gather GL_ARB_texture_query_lod GL_ARB_texture_rgb10_a2ui GL_ARB_texture_storage GL_ARB_texture_swizzle GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_ARB_vertex_attrib_64bit GL_ARB_vertex_type_2_10_10_10_rev GL_ARB_viewport_array GL_EXT_debug_label GL_EXT_debug_marker GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_texture_compression_s3tc GL_EXT_texture_filter_anisotropic GL_EXT_texture_sRGB_decode GL_APPLE_client_storage GL_APPLE_container_object_shareable GL_APPLE_flush_render GL_APPLE_object_purgeable GL_APPLE_rgb_422 GL_APPLE_row_bytes GL_APPLE_texture_range GL_ATI_texture_mirror_once GL_NV_texture_barrier
Disabled Extensions GL_KHR_blend_equation_advanced GL_KHR_blend_equation_advanced_coherent
Disabled WebGL Extensions
Window system binding vendor
Window system binding version
Window system binding extensions
Direct rendering version unknown
Reset notification strategy 0x0000
GPU process crash count 0
gfx::BufferFormats supported for allocation and texturing R_8: not supported, R_16: not supported, RG_88: not supported, BGR_565: not supported, RGBA_4444: not supported, RGBX_8888: not supported, RGBA_8888: not supported, BGRX_8888: not supported, BGRX_1010102: not supported, RGBX_1010102: not supported, BGRA_8888: not supported, RGBA_F16: not supported, YVU_420: not supported, YUV_420_BIPLANAR: not supported, UYVY_422: not supported, P010: not supported
Compositor Information
Tile Update Mode Zero-copy
Partial Raster Enabled
GpuMemoryBuffers Status
R_8 GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE
R_16 Software only
RG_88 Software only
BGR_565 Software only
RGBA_4444 Software only
RGBX_8888 Software only
RGBA_8888 GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE
BGRX_8888 GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE
BGRX_1010102 GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE
RGBX_1010102 Software only
BGRA_8888 GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE
RGBA_F16 GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE
YVU_420 Software only
YUV_420_BIPLANAR GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE
UYVY_422 GPU_READ, SCANOUT, SCANOUT_CPU_READ_WRITE, GPU_READ_CPU_READ_WRITE
P010 Software only
Display(s) Information
Info Display[722476050] bounds=[0,0 3008x1692], workarea=[0,23 3008x1612], scale=2, external.
Color space information {primaries_d50_referred: [[0.6479, 0.3310], [0.3200, 0.5983], [0.1563, 0.0654]], transfer:IEC61966_2_1, matrix:RGB, range:FULL}
SDR white level in nits 80
Bits per color component 8
Bits per pixel 24
Refresh Rate in Hz 59
Video Acceleration Information
Decode h264 baseline up to 4096x2160 pixels
Decode h264 extended up to 4096x2160 pixels
Decode h264 main up to 4096x2160 pixels
Decode h264 high up to 4096x2160 pixels
Encode h264 baseline up to 4096x2160 pixels and/or 30.000 fps
Encode h264 main up to 4096x2160 pixels and/or 30.000 fps
Encode h264 high up to 4096x2160 pixels and/or 30.000 fps
Log Messages
[8722:775:0925/094556.854900:WARNING:ipc_message_attachment_set.cc(49)] : MessageAttachmentSet destroyed with unconsumed attachments: 0/1
[8722:775:0925/094556.854982:WARNING:ipc_message_attachment_set.cc(49)] : MessageAttachmentSet destroyed with unconsumed attachments: 0/1
[8722:775:0925/094603.135831:WARNING:ipc_message_attachment_set.cc(49)] : MessageAttachmentSet destroyed with unconsumed attachments: 0/1
[8722:775:0925/094914.297531:WARNING:ipc_message_attachment_set.cc(49)] : MessageAttachmentSet destroyed with unconsumed attachments: 0/1
[8722:775:0925/094918.819757:WARNING:ipc_message_attachment_set.cc(49)] : MessageAttachmentSet destroyed with unconsumed attachments: 0/1
[8722:775:0925/095608.153780:WARNING:ipc_message_attachment_set.cc(49)] : MessageAttachmentSet destroyed with unconsumed attachments: 0/1
[8722:775:0925/095745.863140:WARNING:ipc_message_attachment_set.cc(49)] : MessageAttachmentSet destroyed with unconsumed attachments: 0/1
[8722:775:0925/095858.489519:WARNING:ipc_message_attachment_set.cc(49)] : MessageAttachmentSet destroyed with unconsumed attachments: 0/1
[8722:775:0925/095858.514027:ERROR:shared_image_manager.cc(120)] : SharedImageManager::ProduceGLTexture: Trying to produce a representation from a non-existent mailbox. 3E:E5:58:D7:F9:48:AF:41:8F:3E:4B:B9:6A:32:0A:57
[8722:775:0925/095858.514132:ERROR:gles2_cmd_decoder.cc(18508)] : [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : DoCreateAndTexStorage2DSharedImageINTERNAL: invalid mailbox name
[8722:775:0925/095858.514175:ERROR:gles2_cmd_decoder.cc(18529)] : [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : DoBeginSharedImageAccessCHROMIUM: bound texture is not a shared image
[8722:775:0925/095858.514309:ERROR:gles2_cmd_decoder.cc(13522)] : [.DisplayCompositor]GL ERROR :GL_INVALID_VALUE : glScheduleCALayerCHROMIUM: unsupported texture format
[8722:775:0925/095858.546486:ERROR:gles2_cmd_decoder.cc(18529)] : [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : DoBeginSharedImageAccessCHROMIUM: bound texture is not a shared image
[8722:775:0925/095858.546553:ERROR:gles2_cmd_decoder.cc(13522)] : [.DisplayCompositor]GL ERROR :GL_INVALID_VALUE : glScheduleCALayerCHROMIUM: unsupported texture format
[8722:775:0925/095858.566879:ERROR:gles2_cmd_decoder.cc(18529)] : [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : DoBeginSharedImageAccessCHROMIUM: bound texture is not a shared image
[8722:775:0925/095858.566914:ERROR:gles2_cmd_decoder.cc(13522)] : [.DisplayCompositor]GL ERROR :GL_INVALID_VALUE : glScheduleCALayerCHROMIUM: unsupported texture format
[8722:775:0925/095858.578570:ERROR:gles2_cmd_decoder.cc(18552)] : [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : DoEndSharedImageAccessCHROMIUM: bound texture is not a shared image
[8722:775:0925/095858.578862:ERROR:gles2_cmd_decoder.cc(18529)] : [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : DoBeginSharedImageAccessCHROMIUM: bound texture is not a shared image
[8722:775:0925/095858.579115:ERROR:gles2_cmd_decoder.cc(13522)] : [.DisplayCompositor]GL ERROR :GL_INVALID_VALUE : glScheduleCALayerCHROMIUM: unsupported texture format
[8722:775:0925/095858.581658:ERROR:gles2_cmd_decoder.cc(18552)] : [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : DoEndSharedImageAccessCHROMIUM: bound texture is not a shared image
[8722:775:0925/095858.583710:ERROR:gles2_cmd_decoder.cc(18529)] : [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : DoBeginSharedImageAccessCHROMIUM: bound texture is not a shared image
[8722:775:0925/095858.583739:ERROR:gles2_cmd_decoder.cc(13522)] : [.DisplayCompositor]GL ERROR :GL_INVALID_VALUE : glScheduleCALayerCHROMIUM: unsupported texture format
[8722:775:0925/095858.586446:ERROR:gles2_cmd_decoder.cc(18552)] : [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : DoEndSharedImageAccessCHROMIUM: bound texture is not a shared image
[8722:775:0925/095858.598595:ERROR:gles2_cmd_decoder.cc(18552)] : [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : DoEndSharedImageAccessCHROMIUM: bound texture is not a shared image
[8722:775:0925/095858.598702:ERROR:gles2_cmd_decoder.cc(18529)] : [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : DoBeginSharedImageAccessCHROMIUM: bound texture is not a shared image
[8722:775:0925/095858.598759:ERROR:gles2_cmd_decoder.cc(13522)] : [.DisplayCompositor]GL ERROR :GL_INVALID_VALUE : glScheduleCALayerCHROMIUM: unsupported texture format
[8722:775:0925/095858.601623:ERROR:gles2_cmd_decoder.cc(18552)] : [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : DoEndSharedImageAccessCHROMIUM: bound texture is not a shared image
[8722:775:0925/095858.607576:ERROR:gles2_cmd_decoder.cc(18529)] : [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : DoBeginSharedImageAccessCHROMIUM: bound texture is not a shared image
[8722:775:0925/095858.607607:ERROR:gles2_cmd_decoder.cc(13522)] : [.DisplayCompositor]GL ERROR :GL_INVALID_VALUE : glScheduleCALayerCHROMIUM: unsupported texture format
[8722:775:0925/095858.608004:ERROR:gles2_cmd_decoder.cc(18552)] : [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : DoEndSharedImageAccessCHROMIUM: bound texture is not a shared image
[8722:775:0925/095858.687860:ERROR:gles2_cmd_decoder.cc(18552)] : [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : DoEndSharedImageAccessCHROMIUM: bound texture is not a shared image
This is hitting us very hard, we have thousands of customers who rely on our video analysis pipeline and these kinds of regressions are detrimental to our business. Please implement an integration test suite to make sure this does not happen again. Thank you.