kc3-lang/angle/src/tests/egl_tests/EGLMultiContextTest.cpp

src/tests/egl_tests/EGLMultiContextTest.cpp

Log

Author Commit Date CI Message
Roman Lavrov 13456bfc 2022-08-23T13:33:13 Propagate device type in another eglGetPlatformDisplayEXT call. Same as https://crrev.com/c/3759712 for another test. Also use !platformSupportsMultithreading() to skip tests. However, need to skip separately from capture/replay where multi-threaded tests seem to run into issues. Bug: angleproject:7494 Bug: angleproject:7423 Change-Id: Ief87b4163aedd26b440987540c06ceb7ae8a575b Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3851166 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Roman Lavrov <romanl@google.com>
Roman Lavrov 16e7226d 2022-07-13T17:56:36 Propagate device type in ReuseUnterminatedDisplay. Fixes the issue with SwiftShader from https://crrev.com/c/3717277 Bug: angleproject:7494 Change-Id: Icb83087caf789518b0c3f30b10b543b299a500bc Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3759712 Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Auto-Submit: Roman Lavrov <romanl@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Mohan Maiya 12efe5b2 2022-06-21T15:43:42 Cleanup invalid EGL handles only if app called eglTermiate Maintain set of active threads instead of a global refCount and free display's invalid EGL resources iff - 1. app previously called eglTerminate on that display 2. there are no more active threads associated with that display Bug: angleproject:6723 Test: EGLMultiContextTest.RepeatedEglInitAndTerminate* Test: EGLMultiContextTest.ReuseUnterminatedDisplay* Change-Id: I868491bbbf0664e9129dcb0d1fa9e2243ef36d82 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3717277 Commit-Queue: mohan maiya <m.maiya@samsung.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Roman Lavrov <romanl@google.com>
Eddie Hatfield 89e38b57 2022-06-22T15:04:08 Refactor to use ANGLETest vs ANGLETestWithParam Bug: angleproject:6747 Change-Id: I72ad52d0268eae0e1a401f12f3e94cc5efa402f2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3719002 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Cody Northrop <cnorthrop@google.com>
Shahbaz Youssefi 3dfc8004 2022-06-08T14:24:48 Vulkan: Optimize sync followed by swap Previously, inserting a sync object immediately caused a submission. That was done in https://chromium-review.googlesource.com/c/angle/angle/+/3200274 to be able to wait until the sync object is signaled without having to wait for whatever is recorded after it until a flush naturally happens. Some applications issue a glFenceSync right before eglSwapBuffers. The submission incurred by glFenceSync disallowed the optimizations that eglSwapBuffers would have done, leading to performance degradations. This could have been avoided if glFenceSync was issued right after eglSwapBuffers, but that's not the case with a number of applications. In this change, when a fence is inserted: - For EGL sync objects, a submission is issued regardless - For GL sync objects, a submission is issued if there is no render pass open - For GL sync objects, the submission is deferred if there is an open render pass. This is done by marking the render pass closed, and flagging the context as having a deferred flash. If the context that issued the fence sync issues another draw call, the render pass is naturally closed and the submission is performed. If the context that issued the fence sync causes a submission, it would have a chance to modify the render pass before doing so. For example, it could apply swapchain optimizations before swapping, or add a resolve attachment for blit. If the context that issued the fence sync doesn't cause a submission before another context tries to access it (get status, wait, etc), the other context will flush its render pass and cause a submission on its behalf. This is possible because the deferral of submission is done only for GL sync objects, and those are only accessible by other contexts in the same share group. Bug: angleproject:7379 Change-Id: I3dd1c1bfd575206d730dd9ee2e33ba2254318521 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3695520 Reviewed-by: Charlie Lao <cclao@google.com> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org>
Mohan Maiya feb599ad 2021-12-09T20:17:14 Invalidate EGL handles during eglTerminate EGL 1.5 spec says - Termination marks all EGL-specific resources, such as contexts and surfaces, associated with the specified display for deletion. Handles to all such resources are invalid as soon as eglTerminate returns Move EGL object handles to another set, tracking invalid objects, during display terminate. Destroy these invalid objects during eglReleaseThread Bug: angleproject:6798 Test: EGLMultiContextTest.NegativeTestAfterEglTerminate* Test: EGLMultiContextTest.RepeatedEglInitAndTerminate* Test: Android CTS WrapperTest.testThreadCleanup Change-Id: Ie160212c98367493e645d9d1c8260e7a30649386 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3329273 Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Commit-Queue: mohan maiya <m.maiya@samsung.com>
Mohan Maiya 6c172e4b 2021-11-20T16:27:14 Add support for memory cleanup on process exit This patch adds a callback to cleanup memory on process exit. Bug: angleproject:6723 Test: Android CTS WrapperTest.testThreadCleanup Change-Id: Ia517d4c6ae280ddc1f17a3b6f77d437aaaad0678 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3294581 Reviewed-by: Jamie Madill <jmadill@chromium.org> Reviewed-by: Tim Van Patten <timvp@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org> Commit-Queue: Mohan Maiya <m.maiya@samsung.com>
Geoff Lang d2c01d2c 2021-09-17T12:57:14 GL: Allow selecting virtualization groups at context creation Rewrite EGL_ANGLE_platform_angle_context_virtualization to EGL_ANGLE_context_virtualization, changing the context virtualization parameter to an identifier for what virtualization group the frontend context should be added to. This allows ANGLE's GL backend to be used by multiple threads if the user creates contexts with different virtualization groups. Bug: angleproject:6406 Change-Id: I7414d4705ce10bdf63a9b824043d5dd040dad875 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3169193 Reviewed-by: Jonah Ryan-Davis <jonahr@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Geoff Lang <geofflang@chromium.org>
Tim Van Patten 8bb3c827 2021-07-22T19:06:40 Fix Multithreaded eglDestroyContext()/eglTerminate() The following EGL calls can lead to a crash in eglMakeCurrent(): Thread A: eglMakeCurrent(context A) Thread B: eglDestroyContext(context A) B: eglTerminate() <<--- this release context A Thread A: eglMakeCurrent(context B) The eglMakeCurrent(context B) call will assert when attempting to unMakeCurrent(), since thread A doesn't know that context A was already destroyed by thread B. To fix this: 1.) A Context will only be released once there are no Threads that currently have a reference to it (no longer have the Context current). - Context::mIsCurrent is being removed, since it was inaccurate and not thread-safe. For example, when eglTerminate() was called, the eglTerminate()'ing-Thread would "steal" the Context that was current on another Thread to destroy it. 2.) A Display will only be fully terminated and its resources released once all Contexts have been destroyed and are no longer current. Otherwise, Display::terminate() will return if any Contexts are still in use by a Thread. EGL 1.5 Specification 3.2 Initialization If contexts or surfaces, created with respect to dpy are current (see section 3.7.3) to any thread, then they are not actually destroyed while they remain current. If other resources created with respect to dpy are in use by any current context or surface, then they are also not destroyed until the corresponding context or surface is no longer current. With this fix, the app com.netmarble.sknightsmmo can start. This also exposed an issue with GlslangFinalize(), since glslang can only be initialized/finalized once per process. Otherwise, the following EGL commands will call GlslangFinalize() without ever being able to GlslangInitialize() again, leading to crashes since GlslangFinalize() cleans up glslang for the entire process. dpy1 = eglGetPlatformDisplay() | eglInitialize(dpy1) | GlslangInitialize() dpy2 = eglGetPlatformDisplay() | eglInitialize(dpy2) | GlslangInitialize() eglTerminate(dpy2) | GlslangFinalize() eglInitialize(dpy1) | isInitialized() == true Since Display::isInitialized() == true, the rest of Display::initialize() is skipped and GlslangInitialize() is not called. Later, the next test that attempts to compile a program will crash due to glslang no longer being initialized. Finally, this exposed the following tests leaking EGLContext handles: - EGLSurfaceTest::initializeContext() - EGLContextSharingTest.DisplayShareGroupContextCreation - EGLCreateContextAttribsTest.IMGContextPriorityExtension - EGLMultiContextTest.TestContextDestroySimple Other tests were failing to reset the context, preventing the Display from being terminated since there were still references to Contexts owned by the display: eglMakeCurrent(dpy, EGL_NO_SURFACE, EGL_NO_SURFACE, EGL_NO_CONTEXT); Bug: angleproject:6208 Bug: angleproject:6304 Bug: angleproject:6322 Test: EGLContextSharingTest.EglTerminateMultiThreaded Test: EGLContextSharingTestNoFixture.EglDestoryContextManyTimesSameContext Test: Load com.netmarble.sknightsmmo Change-Id: I160922af93db6cabe0ed396be77762fa8dfc7656 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3046961 Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Tim Van Patten <timvp@google.com>
Tim Van Patten 460618ad 2021-08-20T18:34:10 Refactor EGLMultiThreadSteps.h -> MultiThreadSteps.h The class ThreadSynchronization is very useful when synchronizing multiple threads in ANGLE tests, so it's being moved from egl_tests/EGLMultiThreadSteps.h to test_utils/MultiThreadSteps.h. Bug: angleproject:5971 Change-Id: I5df469aa68b79cf72d95e0276f42ab33a091314e Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3111887 Reviewed-by: Ian Elliott <ianelliott@google.com> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Tim Van Patten <timvp@google.com>
Doug Horn fdba40fe 2021-03-31T12:52:00 Reland "Fix multithreaded crash on draw commands on D3D11 backend." This is a reland of 8b9889bf62272fea2495331b622bde1f7c781bd0 The previous CL relied on a define which now only exists in a specific gn configuration. This reland removes D3D11 as a multithread-supported platform in the test configuration. Original change's description: > Fix multithreaded crash on draw commands on D3D11 backend. > > A crash can occur if thread A is executing eglDestroyContext while > thread B issues a draw call, if the threads are interleaved in such a > manner that a makeCurrent occurs without triggering a change to the > global context and a dirtyAllState call. We handle that case by > explicitly making current the proper contexts in the eglDestroyContext > call. > > A test has been added that triggers a crash without this fix when > running on the D3D11 backend. In addition, all of MultithreadingTest > is enabled for the D3D11 backend. > > Test: Ran MultithreadingTest. Test exhibits a crash before this > change, and does not after this change. Also ran: > dEQP-EGL.functional.sharing.gles2.multithread.* > dEQP-EGL.functional.multithread.* > > Bug: b/183756357 > Change-Id: Ic6f76a062868b2f3b4e60d29dc087ec180bfb7cd > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2798591 > Reviewed-by: Geoff Lang <geofflang@chromium.org> > Reviewed-by: Jamie Madill <jmadill@chromium.org> > Commit-Queue: Doug Horn <doughorn@google.com> Bug: b/183756357 Change-Id: I5be9a011ea99a69730eddc9e4da23bcf92ed3bf2 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2815243 Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Doug Horn <doughorn@google.com>
Doug Horn fc189386 2021-04-08T21:51:46 Revert "Fix multithreaded crash on draw commands on D3D11 backend." This reverts commit 8b9889bf62272fea2495331b622bde1f7c781bd0. Reason for revert: Breaks CI Original change's description: > Fix multithreaded crash on draw commands on D3D11 backend. > > A crash can occur if thread A is executing eglDestroyContext while > thread B issues a draw call, if the threads are interleaved in such a > manner that a makeCurrent occurs without triggering a change to the > global context and a dirtyAllState call. We handle that case by > explicitly making current the proper contexts in the eglDestroyContext > call. > > A test has been added that triggers a crash without this fix when > running on the D3D11 backend. In addition, all of MultithreadingTest > is enabled for the D3D11 backend. > > Test: Ran MultithreadingTest. Test exhibits a crash before this > change, and does not after this change. Also ran: > dEQP-EGL.functional.sharing.gles2.multithread.* > dEQP-EGL.functional.multithread.* > > Bug: b/183756357 > Change-Id: Ic6f76a062868b2f3b4e60d29dc087ec180bfb7cd > Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2798591 > Reviewed-by: Geoff Lang <geofflang@chromium.org> > Reviewed-by: Jamie Madill <jmadill@chromium.org> > Commit-Queue: Doug Horn <doughorn@google.com> Bug: b/183756357 Change-Id: I2e9d6385576330f84623d7dafbf690642fcb441f No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2815242 Commit-Queue: Doug Horn <doughorn@google.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Doug Horn 8b9889bf 2021-03-31T12:52:00 Fix multithreaded crash on draw commands on D3D11 backend. A crash can occur if thread A is executing eglDestroyContext while thread B issues a draw call, if the threads are interleaved in such a manner that a makeCurrent occurs without triggering a change to the global context and a dirtyAllState call. We handle that case by explicitly making current the proper contexts in the eglDestroyContext call. A test has been added that triggers a crash without this fix when running on the D3D11 backend. In addition, all of MultithreadingTest is enabled for the D3D11 backend. Test: Ran MultithreadingTest. Test exhibits a crash before this change, and does not after this change. Also ran: dEQP-EGL.functional.sharing.gles2.multithread.* dEQP-EGL.functional.multithread.* Bug: b/183756357 Change-Id: Ic6f76a062868b2f3b4e60d29dc087ec180bfb7cd Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2798591 Reviewed-by: Geoff Lang <geofflang@chromium.org> Reviewed-by: Jamie Madill <jmadill@chromium.org> Commit-Queue: Doug Horn <doughorn@google.com>
Ian Elliott c4b1f366 2021-03-22T17:56:54 Fix copyright dates of new test files per Shabi Bug: b/181711029 Change-Id: Ie619ba90f699dd8234cf185198cb6eeac9142758 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2780560 Reviewed-by: Ian Elliott <ianelliott@google.com> Commit-Queue: Ian Elliott <ianelliott@google.com>
Ian Elliott 90cf278c 2021-03-19T16:17:43 Add multi-thread/context test for compute shaders The "Ragnarok M: Eternal Love" game uncovered a bug where 2 contexts shared a VkCommandBuffer. The one context was used by one thread for rendering, and the other context/thread dispatched compute shaders. When the rendering thread destroyed a VkCommandBuffer, future compute dispatches crashed because the new VkCommandBuffer didn't have a compute pipeline bound. Bug: b/181711029 Change-Id: I8bc85150c1c6202e02feb84a7ccc0ad7b9c39258 Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/2770681 Commit-Queue: Ian Elliott <ianelliott@google.com> Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
kmx.io     mail     discord kmxgit v0.4.0