Flakyness in WebGL2 conformance tests with video |
||||||||||||
Issue descriptionFlakyness has started showing up across the whole GPU FYI waterfall with various WebGL2 video tests. All desktop platforms appear to be affected. Example: https://build.chromium.org/p/chromium.gpu.fyi/builders/Win7%20Release%20%28NVIDIA%29/builds/25925 https://build.chromium.org/p/chromium.gpu.fyi/builders/Linux%20Release%20%28ATI%29/builds/48492 https://build.chromium.org/p/chromium.gpu.fyi/builders/Mac%20Retina%20Release/builds/5019 Regression range isn't obvious yet, looking for suspect CLs.
,
Jun 30 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/b2271028e1934c5b9c607b75e31b27b195c18c6e commit b2271028e1934c5b9c607b75e31b27b195c18c6e Author: geofflang <geofflang@chromium.org> Date: Thu Jun 30 17:41:29 2016 Revert of Fix MultibufferDataSource::GetSize (patchset #1 id:1 of https://codereview.chromium.org/2110853006/ ) Reason for revert: I believe this CL is causing flakyness in the video related tests on the GPU FYI waterfall. Examples: https://build.chromium.org/p/chromium.gpu.fyi/builders/Win7%20Release%20%28NVIDIA%29/builds/25925 https://build.chromium.org/p/chromium.gpu.fyi/builders/Linux%20Release%20%28ATI%29/builds/48492 https://build.chromium.org/p/chromium.gpu.fyi/builders/Mac%20Retina%20Release/builds/5019 Seeing this in the output log: [27562:1287:0630/083352:WARNING:webmediaplayer_impl.cc(335)] Using MultibufferDataSource [27562:34423:0630/083352:ERROR:ffmpeg_demuxer.cc(1510)] OnReadFrameDone result=-541478725 IsMaxMemoryUsageReached=0 [27562:1287:0630/083352:WARNING:webmediaplayer_impl.cc(335)] Using MultibufferDataSource [27562:1287:0630/083352:FATAL:resource_multibuffer_data_provider.cc(75)] Check failed: byte_pos() < url_data_->length() (32768 vs. 10292) http://127.0.0.1:53903/resources/red-green.theora.ogv Original issue's description: > Fix MultibufferDataSource::GetSize > > When file loading is finished ResourceMultiBufferDataProvider count > DataBuffer queue size twice, so GetSize returned incorrect value. > > BUG= > > Committed: https://crrev.com/bbaba3c8053a39f6d11d78a6e4770b37a9639067 > Cr-Commit-Position: refs/heads/master@{#403123} TBR=hubbe@chromium.org,kostya-k@yandex-team.ru # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= 624853 Review-Url: https://codereview.chromium.org/2115483003 Cr-Commit-Position: refs/heads/master@{#403211} [modify] https://crrev.com/b2271028e1934c5b9c607b75e31b27b195c18c6e/media/blink/multibuffer_data_source_unittest.cc [modify] https://crrev.com/b2271028e1934c5b9c607b75e31b27b195c18c6e/media/blink/resource_multibuffer_data_provider.cc
,
Jun 30 2016
,
Jul 12 2016
This still appears to be happening: WebglConformance_conformance_textures_video_tex_2d_rgba_rgba_unsigned_short_5_5_5_1 (gpu_tests.webgl_conformance_integration_test.WebGLConformanceIntegrationTest) ... 11283:1299:0712/093736:WARNING:webmediaplayer_impl.cc(335)] Using MultibufferDataSource [11283:1299:0712/093737:WARNING:webmediaplayer_impl.cc(335)] Using MultibufferDataSource [11283:1299:0712/093737:FATAL:resource_multibuffer_data_provider.cc(76)] Check failed: byte_pos() < url_data_->length() (32768 vs. 21958) http://127.0.0.1:55011/resources/red-green.webmvp8.webm From: https://build.chromium.org/p/chromium.gpu/builders/Mac%2010.10%20Debug%20%28Intel%29/builds/11741/steps/webgl_conformance_tests%20on%20Intel%20GPU%20on%20Mac%20on%20Mac-10.10/logs/stdio Similar build failure: https://build.chromium.org/p/chromium.gpu/builders/Mac%2010.10%20Debug%20%28Intel%29/builds/11750/steps/webgl_conformance_tests%20on%20Intel%20GPU%20on%20Mac%20on%20Mac-10.10/logs/stdio
,
Jul 12 2016
,
Jul 12 2016
,
Jul 12 2016
,
Jul 12 2016
,
Jul 12 2016
,
Jul 13 2016
I suggest relanding https://codereview.chromium.org/2110853006/, assuming it is correct. Now WebglConformance_conformance2_textures_video_tex_* failures seem to be somewhat random, see https://build.chromium.org/p/chromium.gpu.fyi/builders/Win7%20Release%20%28New%20Intel%29/builds/1121/steps/webgl2_conformance_tests/logs/stdio for example. Having it fail on size check should be more consistent than failing from accessing random memory.
,
Jul 13 2016
,
Jul 13 2016
An updated CL is in the commit queue here: https://codereview.chromium.org/2133803004/
,
Jul 13 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6e50a4b489e2c06e368ee239911e8191b1a507e9 commit 6e50a4b489e2c06e368ee239911e8191b1a507e9 Author: hubbe <hubbe@chromium.org> Date: Wed Jul 13 19:55:10 2016 Fix MultibufferDataSource::GetSize When file loading is finished ResourceMultiBufferDataProvider count DataBuffer queue size twice, so GetSize returned incorrect value. BUG= 625515 , 627525 , 624853 patch from issue 2110853006 at patchset 1 (http://crrev.com/2110853006#ps1) Review-Url: https://codereview.chromium.org/2133803004 Cr-Commit-Position: refs/heads/master@{#405242} [modify] https://crrev.com/6e50a4b489e2c06e368ee239911e8191b1a507e9/media/blink/multibuffer_data_source_unittest.cc [modify] https://crrev.com/6e50a4b489e2c06e368ee239911e8191b1a507e9/media/blink/resource_multibuffer_data_provider.cc [modify] https://crrev.com/6e50a4b489e2c06e368ee239911e8191b1a507e9/media/blink/resource_multibuffer_data_provider.h
,
Jul 13 2016
Now the failure looks consistent. Does ERROR:ffmpeg_demuxer.cc(1595)] OnReadFrameDone result=-541478725 IsMaxMemoryUsageReached=0 make sense to anyone on this thread?
,
Jul 13 2016
Is the test still failing? Could be harmless otherwise, that can occur when the DataSource is aborted for tag destruction.
,
Jul 13 2016
The test is reported as passing, but I'm not sure if the report is correct. Tests running after it are failing, but I suspect that *from_video_tex* running before them may actually be the cause. See here: https://build.chromium.org/p/chromium.gpu.fyi/builders/Win7%20Release%20%28NVIDIA%29/builds/26389/steps/webgl2_conformance_tests%20on%20NVIDIA%20GPU%20on%20Windows%20on%20Windows-2008ServerR2-SP1/logs/stdio
,
Jul 13 2016
Actually, could be that the video tests were fixed, and these are new failures. Sorry for spam.
,
Jul 14 2016
So with the GetSize fix, is this still an issue?
,
Jul 14 2016
Looks like it to me, at least on https://build.chromium.org/p/chromium.gpu/builders/Mac%2010.10%20Debug%20%28Intel%29?numbuilds=200 which had been reliably hitting that bug just prior to that change in build 11832.
,
Jul 14 2016
Er, looks like it's been fixed to me, sorry.
,
Jul 14 2016
Now I wish I could put this bug in a superposition of "Fixed" and "Assigned". :)
,
Jul 14 2016
I still see it https://build.chromium.org/p/chromium.gpu.fyi/builders/Win7%20Release%20%28New%20Intel%29/builds/1131
,
Jul 14 2016
Is that the same problem? Here's the log excerpt: WebglConformance_conformance2_textures_video_tex_2d_rgb9_e5_rgb_half_float (gpu_tests.webgl_conformance_integration_test.WebGLConformanceIntegrationTest) ... [1536:2336:0714/093700:WARNING:webmediaplayer_impl.cc(335)] Using MultibufferDataSource [3580:3088:0714/093700:ERROR:audio_manager_win.cc(464)] GetPreferredAudioParameters failed: 88890004 [3572:1652:0714/093700:INFO:gpu_video_decode_accelerator_factory_impl.cc(163)] Initializing DXVA HW decoder for windows. [3580:3088:0714/093700:ERROR:audio_manager_win.cc(464)] GetPreferredAudioParameters failed: 88890004 [3580:3088:0714/093700:ERROR:audio_output_resampler.cc(240)] Unable to open audio device in low latency mode. Falling back to high latency audio output. [3580:3088:0714/093700:ERROR:audio_output_resampler.cc(250)] Unable to open audio device in high latency mode. Falling back to fake audio output. [3572:1652:0714/093700:ERROR:dxva_video_decode_accelerator_win.cc(452)] The eglQueryDeviceAttribEXT function failed to get the device [3572:1652:0714/093700:ERROR:dxva_video_decode_accelerator_win.cc(222)] Error in dxva_video_decode_accelerator_win.cc on line 452 [1536:2336:0714/093700:WARNING:webmediaplayer_impl.cc(335)] Using MultibufferDataSource [3572:1652:0714/093700:INFO:gpu_video_decode_accelerator_factory_impl.cc(163)] Initializing DXVA HW decoder for windows. [3572:1652:0714/093700:ERROR:dxva_video_decode_accelerator_win.cc(1465)] Unsupported codec. [3572:1652:0714/093700:ERROR:dxva_video_decode_accelerator_win.cc(222)] Error in dxva_video_decode_accelerator_win.cc on line 1465 [3572:1652:0714/093700:ERROR:dxva_video_decode_accelerator_win.cc(222)] Error in dxva_video_decode_accelerator_win.cc on line 709 [3572:1652:0714/093700:ERROR:gpu_video_decode_accelerator.cc(365)] HW video decode not available for profile 11 [1536:3740:0714/093700:ERROR:gpu_video_decode_accelerator_host.cc(93)] Send(GpuCommandBufferMsg_CreateVideoDecoder()) failed [1536:3740:0714/093700:ERROR:gpu_video_decoder.cc(801)] VDA Error: 4 [3572:1868:0714/093700:ERROR:gpu_channel.cc(569)] Could not find message queue [1536:3740:0714/093700:ERROR:ffmpeg_demuxer.cc(1595)] media::FFmpegDemuxer::OnReadFrameDone result=-541478725 IsMaxMemoryUsageReached=0 err: rx::SwapChain11::present(826): Present failed: the D3D11 device was removed: 0x887A0006 [3572:1652:0714/093704:ERROR:gles2_cmd_decoder.cc(13747)] Context lost because SwapBuffers failed. [3572:1652:0714/093704:ERROR:gles2_cmd_decoder.cc(14105)] Onscreen context lost via ARB/EXT_robustness. Reset status = GL_UNKNOWN_CONTEXT_RESET_KHR [3572:1652:0714/093704:ERROR:gles2_cmd_decoder.cc(5040)] Error: 5 for Command kPostSubBufferCHROMIUM [3572:1652:0714/093704:ERROR:gpu_channel_manager.cc(222)] Exiting GPU process because some drivers cannot recover from problems. hubbe, same problem or different one? If different, let's file it and move this to fixed again.
,
Jul 14 2016
It's not the same as the DCHECK listed in #4 at least. (Impossible, since the DCHECK is now gone.) I don't know what is causing this failure.
,
Jul 14 2016
OK, let's call this fixed then and file a new bug. The failure above is happening 100% of the time on that particular bot. Thanks for fixing this.
,
Jul 14 2016
,
Jul 14 2016
I still think this is flaky. Nothing has really been fixed. The bug was opened because of flakiness starting around https://codereview.chromium.org/2110853006/, which was reverted and relanded. Now we should be back at the starting point. Set of failing tests across builds is different: https://build.chromium.org/p/chromium.gpu.fyi/builders/Win7%20Release%20%28New%20Intel%29/builds/1130 WebglConformance_conformance2_textures_video_tex_2d_rgb5_a1_rgba_unsigned_byte WebglConformance_conformance2_textures_video_tex_2d_rgb9_e5_rgb_half_float WebglConformance_conformance2_textures_video_tex_2d_rgba32f_rgba_float https://build.chromium.org/p/chromium.gpu.fyi/builders/Win7%20Release%20%28New%20Intel%29/builds/1131 WebglConformance_conformance2_textures_video_tex_2d_rgb9_e5_rgb_half_float https://build.chromium.org/p/chromium.gpu.fyi/builders/Win7%20Release%20%28New%20Intel%29/builds/1132 WebglConformance_conformance2_textures_video_tex_2d_rg32f_rg_float WebglConformance_conformance2_textures_video_tex_2d_rgb5_a1_rgba_unsigned_byte WebglConformance_conformance2_textures_video_tex_2d_rgba32f_rgba_float
,
Jul 14 2016
Thanks for pointing this out Yuly. I'd missed the fact that different tests are failing on each run on this machine. I still think it's a different problem, and one that's specific to Win/Intel. I've generalized the description on Issue 628395 and provided more information. If flakiness is seen on more machines (like Mac Retina, or Linux) then let's reopen this; otherwise let's leave it fixed.
,
Jun 20 2017
|
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by geoffl...@chromium.org
, Jun 30 2016Status: Started (was: Untriaged)