Bug 246777
Summary: | [ANGLE] Render pipeline descriptor missing causes GPU-process crash | ||
---|---|---|---|
Product: | WebKit | Reporter: | Kyle Piddington <kpiddington> |
Component: | ANGLE | Assignee: | Kyle Piddington <kpiddington> |
Status: | RESOLVED FIXED | ||
Severity: | Normal | CC: | dino, kbr, kkinnunen, webkit-bug-importer |
Priority: | P2 | Keywords: | InRadar |
Version: | WebKit Nightly Build | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
Kyle Piddington
Following on from https://bugs.webkit.org/show_bug.cgi?id=240896, we are still experiencing some cases where the Metal backend does not
correctly configure the render pipeline state. In rarer cases, we end up in a state where the render encoder is valid, but the pipeline state is not set.
Attempt to correct this error with three additional checks
1) When setting up a program, if the render encoder in question does not have a render pipeline state set, attempt to set it, even if the render pass descriptor has not changes.
2) When validating if an encoder is valid, also check if it has a valid render pipeline state during setupDraw. After setupDrawImpl, it should either be invalid (Due to a flush and invalidate all) or not have a render pipeline state (Due to a misconfiguration on the program, or within the state bits.)
If we end up in the case of 2, attempt to set up the program one more time. (Usually due to a flush and invalidate all). If we've failed to create a render encoder again, attempt to recover the graphics context by dropping flushing the command buffer, invalidating the entire GL state, and dropping the draw call. This may lead to a rendering error, but will not cause a browser crash.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Kyle Piddington
Pull request: https://github.com/WebKit/WebKit/pull/5570
Kenneth Russell
Can a symbolized stack trace (just inside ANGLE) be posted here, or maybe better, in a new bug on ANGLE's issue tracker? This sounds like something desirable to track down and fix in the future, and the changes in the PR might make this more difficult to track down.
Kyle Piddington
Unfortunately, the stack trace isn't too helpful for debugging how we got into this state. It's showing a crash on the render command encoder at draw encode time, but the problem would have occurred at setupDraw time, outside of the stack. Essentially, we're crashing because we're drawing without setting a render pipeline state, the equivalent of trying to draw without a program.
That being said, here's our trace, with driver stacks redacted:
0 AGXMetalG14 0x232f790b8
1 AGXMetalG14 0x232f7a714
2 AGXMetalG14 0x232f7a714
3 libANGLE-shared.dylib 0x1f0b942d0 rx::mtl::RenderCommandEncoder::endEncodingImpl(bool) + 360 (Sources/ANGLE/Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/mtl_command_buffer.mm:1308)
4 libANGLE-shared.dylib 0x1f0a813d8 rx::ContextMtl::endRenderEncoding(rx::mtl::RenderCommandEncoder*) + 52 (Sources/ANGLE/Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/mtl_command_buffer.mm:1146)
5 libANGLE-shared.dylib 0x1f0a814c4 rx::ContextMtl::endEncoding(bool) + 156 (Sources/ANGLE/Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/ContextMtl.mm:1678)
6 libANGLE-shared.dylib 0x1f0a820b8 rx::ContextMtl::onDrawFrameBufferChangedState(gl::Context const*, rx::FramebufferMtl*, bool) + 156 (Sources/ANGLE/Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/ContextMtl.mm:2059)
7 libANGLE-shared.dylib 0x1f0b40ec4 rx::FramebufferMtl::syncState(gl::Context const*, unsigned int, angle::BitSetT<29ul, unsigned long long, unsigned long> const&, gl::Command) + 1096 (Sources/ANGLE/Source/ThirdParty/ANGLE/src/libANGLE/renderer/metal/FrameBufferMtl.mm:701)
8 libANGLE-shared.dylib 0x1f0b38cd8 gl::Framebuffer::syncState(gl::Context const*, unsigned int, gl::Command) const + 88 (Sources/ANGLE/Source/ThirdParty/ANGLE/src/libANGLE/Framebuffer.cpp:2066)
9 libANGLE-shared.dylib 0x1f0a6a238 gl::Context::syncState(angle::BitSetT<64ul, unsigned long long, unsigned long> const&, angle::BitSetT<12ul, unsigned long long, unsigned long> const&, gl::Command) + 120 (Sources/ANGLE/Source/ThirdParty/ANGLE/src/libANGLE/State.h:1182)
10 libANGLE-shared.dylib 0x1f0a6a418 gl::Context::blitFramebuffer(int, int, int, int, int, int, int, int, unsigned int, unsigned int) + 284 (Sources/ANGLE/Source/ThirdParty/ANGLE/src/libANGLE/Context.cpp:5578)
11 libANGLE-shared.dylib 0x1f0ae4574 GL_BlitFramebufferANGLE + 292 (Sources/ANGLE/Source/ThirdParty/ANGLE/src/libGLESv2/entry_points_gles_ext_autogen.cpp:658)
12 WebCore 0x1be14c9d4 WebCore::GraphicsContextGLANGLE::resolveMultisamplingIfNecessary(WebCore::IntRect const&) + 276 (Sources/WebCore/Source/WebCore/platform/graphics/angle/GraphicsContextGLANGLE.cpp:353)
13 WebCore 0x1be14e3ec WebCore::GraphicsContextGLANGLE::prepareTexture() + 52 (Sources/WebCore/Source/WebCore/platform/graphics/angle/GraphicsContextGLANGLE.cpp:558)
14 WebCore 0x1be1661e0 WebCore::GraphicsContextGLCocoa::prepareForDisplay() + 212 (Sources/WebCore/Source/WebCore/platform/graphics/cocoa/GraphicsContextGLCocoa.mm:698)
15 WebKit 0x1c08b09d0 WebKit::(anonymous namespace)::RemoteGraphicsContextGLCocoa::prepareForDisplay(WTF::CompletionHandler<void (WTF::MachSendRight&&)>&&) + 92 (Sources/WebKit/Source/WebKit/GPUProcess/graphics/RemoteGraphicsContextGLCocoa.cpp:116)
16 WebKit 0x1c08218ec WebKit::RemoteGraphicsContextGL::didReceiveStreamMessage(IPC::StreamServerConnection&, IPC::Decoder&) + 18760 (Sources/WebKit/Source/WebKit/Platform/IPC/HandleMessage.h:145)
17 WebKit 0x1c0ac6cec IPC::StreamConnectionWorkQueue::processStreams() + 812 (Sources/WebKit/Source/WebKit/Platform/IPC/StreamServerConnection.cpp:298)
18 WebKit 0x1c0ac8a68 WTF::Detail::CallableWrapper<IPC::StreamConnectionWorkQueue::startProcessingThread()::$_0, void>::call() + 56 (Sources/WebKit/Source/WebKit/Platform/IPC/StreamConnectionWorkQueue.cpp:112)
19 JavaScriptCore 0x1b7ffb808 WTF::Thread::entryPoint(WTF::Thread::NewThreadContext*) + 352 (Sources/WTF/Source/WTF/wtf/Function.h:82)
20 JavaScriptCore 0x1b7ffda8c WTF::wtfThreadEntryPoint(void*) + 16 (Sources/WTF/Source/WTF/wtf/posix/ThreadingPOSIX.cpp:242)
21 libsystem_pthread.dylib 0x2318306cc _pthread_start + 148 (Sources/libpthread/src/pthread.c:893)
22 libsystem_pthread.dylib 0x23182fba4 thread_start + 8
EWS
Committed 256013@main (bb1da00b9ba8): <https://commits.webkit.org/256013@main>
Reviewed commits have been landed. Closing PR #5570 and removing active labels.
Radar WebKit Bug Importer
<rdar://problem/101589021>