conformance2/buffers/getBufferSubData.html flaky on Linux NVIDIA |
||||||
Issue descriptionThe WebGL 2.0 conformance test conformance2/buffers/getBufferSubData.html is flaky on Linux. Here's an example passing build: https://build.chromium.org/p/chromium.gpu.fyi/builders/Linux%20Release%20%28NVIDIA%29/builds/43900 and several failing builds: https://build.chromium.org/p/chromium.gpu.fyi/builders/Linux%20Release%20%28NVIDIA%29/builds/43901 https://build.chromium.org/p/chromium.gpu.fyi/builders/Linux%20Release%20%28NVIDIA%29/builds/43899 https://build.chromium.org/p/chromium.gpu.fyi/builders/Linux%20Release%20%28NVIDIA%29/builds/43892 https://build.chromium.org/p/chromium.gpu.fyi/builders/Linux%20Release%20%28NVIDIA%29/builds/43886 https://build.chromium.org/p/chromium.gpu.fyi/builders/Linux%20Release%20%28NVIDIA%29/builds/43885 It looks like some state isn't being properly saved and restored in Chrome's virtual context implementation so some OpenGL call in the command buffer service is causing an OpenGL error to be raised. Here's the stack trace: WebglConformance_conformance2_buffers_getBufferSubData (gpu_tests.webgl_conformance_integration_test.WebGLConformanceIntegrationTest) ... [16333:16333:0925/135315:FATAL:gl_context.cc(216)] Check failed: error == GL_NO_ERROR || error == GL_CONTEXT_LOST_KHR. GL error was: 1281 #0 0x7f4171f3b6ae base::debug::StackTrace::StackTrace() #1 0x7f4171f52cfb logging::LogMessage::~LogMessage() #2 0x7f4172991588 gl::GLContext::MakeVirtuallyCurrent() #3 0x7f4176009c74 gpu::GLContextVirtual::MakeCurrent() #4 0x7f417602b1f7 gpu::gles2::GLES2DecoderImpl::MakeCurrent() #5 0x7f417580da8a gpu::GpuCommandBufferStub::MakeCurrent() #6 0x7f417580d231 gpu::GpuCommandBufferStub::OnMessageReceived() #7 0x7f41756d0529 IPC::MessageRouter::RouteMessage() #8 0x7f417580943e gpu::GpuChannel::HandleMessageHelper() #9 0x7f41758091f2 gpu::GpuChannel::HandleMessage() #10 0x7f4171fcea34 base::debug::TaskAnnotator::RunTask() #11 0x7f4171f5a4f5 base::MessageLoop::RunTask() #12 0x7f4171f5a808 base::MessageLoop::DeferOrRunPendingTask() #13 0x7f4171f5ab4b base::MessageLoop::DoWork() #14 0x7f4171f5c549 base::MessagePumpGlib::Run() #15 0x7f4171f59ff1 base::MessageLoop::RunHandler() #16 0x7f4171f7b970 base::RunLoop::Run() #17 0x7f4173e63aac content::GpuMain() #18 0x7f4171b315fe content::RunNamedProcessTypeMain() #19 0x7f4171b3205b content::ContentMainRunnerImpl::Run() #20 0x7f4171b308f0 content::ContentMain() #21 0x7f4170371d5d ChromeMain #22 0x7f4168e49ec5 __libc_start_main #23 0x7f4170371c31 <unknown> cwallez: any advice on what saving/restoring of OpenGL state ANGLE is doing related to glMapBufferRange / glUnmapBuffer would be greatly appreciated.
,
Sep 26 2016
Agree with Corentin - it's essential debug output is turned on and visible in the log. The error above is INVALID_VALUE, but it's not clear what it might be coming from.
,
Sep 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/42f4838225cca9b5516c5046bae04d284bb1ada4 commit 42f4838225cca9b5516c5046bae04d284bb1ada4 Author: kbr <kbr@chromium.org> Date: Mon Sep 26 17:26:56 2016 Suppress flaky getBufferSubData failures on Linux without ANGLE. BUG=650123 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel TBR=zmo@chromium.org NOTRY=true Review-Url: https://codereview.chromium.org/2368883002 Cr-Commit-Position: refs/heads/master@{#420919} [modify] https://crrev.com/42f4838225cca9b5516c5046bae04d284bb1ada4/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py
,
Sep 26 2016
I'm not sure how feasible it is to enable more logging for the WebGL 2.0 suite. The logs are already enormous. If you have a concrete suggestion about what configuration to change on the bots we can see how it'll affect the log sizes locally before enabling it on the bots. I suspect that we're leaving the buffer mapped when switching virtual contexts, causing another context to produce an error later during a draw call.
,
Sep 30 2016
Kai discovered while prototyping getBufferSubDataAsync that the range check validation was completely missing for MapBufferRange in the command buffer. It's unclear how this test ever passed. Thanks Kai for picking this up. Being fixed in https://codereview.chromium.org/2380683003/ .
,
Oct 1 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/6bf82374fb3a17659851bc4e830c063577ba80fd commit 6bf82374fb3a17659851bc4e830c063577ba80fd Author: kainino <kainino@chromium.org> Date: Sat Oct 01 19:45:29 2016 add range check to service-side MapBufferRange BUG=650123 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel Review-Url: https://codereview.chromium.org/2380683003 Cr-Commit-Position: refs/heads/master@{#422326} [modify] https://crrev.com/6bf82374fb3a17659851bc4e830c063577ba80fd/content/test/gpu/gpu_tests/webgl2_conformance_expectations.py [modify] https://crrev.com/6bf82374fb3a17659851bc4e830c063577ba80fd/gpu/command_buffer/service/buffer_manager.h [modify] https://crrev.com/6bf82374fb3a17659851bc4e830c063577ba80fd/gpu/command_buffer/service/gles2_cmd_decoder.cc [modify] https://crrev.com/6bf82374fb3a17659851bc4e830c063577ba80fd/gpu/command_buffer/service/gles2_cmd_decoder_unittest_buffers.cc [modify] https://crrev.com/6bf82374fb3a17659851bc4e830c063577ba80fd/gpu/command_buffer/service/gles2_cmd_decoder_unittest_framebuffers.cc
,
Oct 3 2016
This may still be an issue (10/03): https://build.chromium.org/p/chromium.gpu.fyi/builders/Linux%20Release%20%28NVIDIA%29/builds/44028
,
Oct 4 2016
,
Oct 4 2016
,
Jun 20 2017
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by cwallez@chromium.org
, Sep 26 2016