|
d193d51b
|
2024-06-17T22:46:08
|
|
Replace issue ids post migration to new issue tracker
This change replaces anglebug.com/NNNN links.
Bug: None
Change-Id: I8ac3aec8d2a8a844b3d7b99fc0a6b2be8da31761
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5637912
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
c0386ad4
|
2024-04-05T11:56:17
|
|
AsyncWorkerPool releases shared_ptr<Closure> before notifying
Parallel compile (MainLinkLoadTask, Program::LinkingState)
is dependent on destructor getting called before the event is notified
Repro: https://crrev.com/c/5425924
More details on the parallel compile case, provided by syoussefi@:
"""
A race condition caused the worker pool to sometimes be destroyed from a
worker thread instead of the main thread.
The race condition triggered in the following scenario:
- The MainLinkLoadTask holds on to the worker pool
- This is necessary for the main task to spawn further tasks
asynchronously
- The reference to the worker pool in MainLinkLoadTask is released by
its destructor
- The worker thread dequeues a task (i.e. MainLinkLoadTask) to execute
and holds a reference to it.
- Once the task is run by the worker thread, the worker thread signals
its completion
- (1) At this point, the scope holding the reference to the task
closes and the task is released. However, this is done after
signaling the task's completion.
- On program destruction, the program ensures that all its tasks are
complete
- This uses the signal coming from the worker thread
- (2) On display destruction, the worker pool is destroyed
(by dereferencing it through the shared_ptr)
- The destructor of the worker pool waits for the worker thread, with
the expectation that this wait is done in the main thread.
The race condition led to the assert firing when (2) was done before
(1). Because the task is already signaled complete, the main thread
considers it done and goes ahead with the destruction of the display.
However, until the scope of the worker thread closes, the task itself
is still not destroyed. Since the task is holding a reference to the
worker pool, that prevents the worker pool from getting destroyed too.
Once the display is destroyed, the worker thread closes its scope,
causing the task to be destroyed. In turn, this leads to the worker
pool itself to be destroyed. On destruction, the worker pool would wait
for the worker thread to end which is a deadlock. Fortunately, this was
caught earlier with an ASSERT that wanted to ensure destruction happens
on the main thread.
In this change, the worker thread ensures it releases the task before
signalling it complete, avoiding this issue. Other possible solutions
would have been:
- Release the worker pool from MainLinkLoadTask as soon as the subtasks
are scheduled
- Explicitly call a "destroy" method on the pool, instead of relying on
the destructor to clean up.
"""
Bug: angleproject:8661
Change-Id: I37c9bc8e8f05bce4062d794df449cc3d2c80a093
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5428806
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Roman Lavrov <romanl@google.com>
|
|
|
d4281637
|
2023-11-15T13:17:36
|
|
Add names to worker threads
Bug: angleproject:8417
Change-Id: I5841d194cb695387aa8fe48638cc025173152347
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5034797
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
ade3dacd
|
2023-11-06T21:56:41
|
|
Do compile/link unlocked if not threaded (but thread-safe)
If GL_KHR_parallel_shader_compile is not supported, or it is not used to
do threaded compilation and link, this change lets the compile and link
jobs be done after releasing the share group lock. With
multithreaded/multi-context applications, this allows the other context
(typically the main context) to make progress in the meantime.
A typical scenario where this optimization matters is games seamlessly
loading a new area of the game and performing compilation and link in a
separate context. Before this change, the game would stutter as the
compile/link jobs prevent the main thread from drawing anything. With
this change, the hitching is removed.
Bug: angleproject:8297
Change-Id: I702d84324a7442561b49677bf42c16d650304313
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5006640
Reviewed-by: Charlie Lao <cclao@google.com>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
3e333c7b
|
2023-08-30T13:25:08
|
|
Check that postTask is non-null before calling it.
ANGLE's platform methods are global but Chrome treats them as if they
are per-display. If multiple displays are created, Chrome can reset the
methods for all displays during angle::ResetPlatform.
ANGLE checks that postTask is non-null before creating
DelegateWorkerPool but not before each use of postTask.
Bug: chromium:1476679
Bug: chromium:1475471
Change-Id: Ie84db48d6c85a1befa604224af6c30bd3515aadf
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4827983
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
507f67cc
|
2023-07-14T15:23:48
|
|
Fix cfi issue with Angle invoking worker pool
Mark the function as ignoring cfi-icall because
of broken upstream builds.
https://ci.chromium.org/ui/p/chromium/builders/ci/Linux%20CFI/25615/overview
Bug: angleproject:8256
Change-Id: I63b5fee27bc0565dc6881bd83fd284abc7a9f1f0
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4685324
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
|
|
|
fe08eee8
|
2023-07-12T18:03:30
|
|
Fix Angle creating its own worker pool.
The WorkerPool was created on the first postTask and could create
a number of threads. We were seeing this on blink for iOS where
we would have expected using the delegate's worker pool. However
ANGLE_ENABLED was undefined because it wasn't included. This
caused the comparison of ANGLE_DELEGATE_WORKERS to not work.
Instead of including the header for ANGLE_ENABLED since that would
cause a dependency on libAngle, just use #if X instead, while
this also isn't the best because X can be undefined its a solution
for now.
Bug: angleproject:8256
Change-Id: I5aeb686dcc117feaba884cdea5c89e4b146cb57f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4679894
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
2bc9f1f4
|
2022-10-26T10:38:02
|
|
Lazily create threads in the thread pool
The Vulkan backend doesn't use thread pools normally, so creating
threads is a waste of CPU time. Additionally, creating threads early
causes issues with some sandboxing strategies.
Bug: b/250688943
Change-Id: I33f1b73bdc62f6a0c0b2277ce99ba78a87464486
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3982174
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
025504b9
|
2022-10-17T17:03:03
|
|
Pass worker pools to image load functions
In preparation for the ASTC decoder using threaded decoding.
Bug: b/250688943
Change-Id: I70d669bcb57b900dbb633304182e174aec362203
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3961339
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Reviewed-by: Greg Schlomoff <gregschlom@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|
|
|
fbd7d5fa
|
2022-10-17T17:20:09
|
|
Move thread pool classes to common/
In preparation for access by image_util files.
Bug: b/250688943
Change-Id: I24777269a5071eae9a60f939635d01ed7246461f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/3961454
Reviewed-by: Jamie Madill <jmadill@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
|