Existing implementation uses single `GlobalMutex` for
- EGL calls
- GL calls for Contexts with concurrent access.
This CL introduces abstract `egl::ContextMutex` with two
implementations:
- SingleContextMutex;
- SharedContextMutex<Mutex>;
Note:
`std::mutex` is used in this commit. It is very easy to change mutex
type either at compile-time or at run-time (single type per Display).
When Context:
- is not Shared;
- does not use `EGLImage`s;
- does not use EGL_DISPLAY_TEXTURE_SHARE_GROUP_ANGLE
- does not use EGL_DISPLAY_SEMAPHORE_SHARE_GROUP_ANGLE
then it will be using `SingleContextMutex` with minimal overhead.
Before such Context is used as `shareContext` or uses `EGLImage`
its mutex replaced by `SharedContextMutex<Mutex>`.
The `GlobalMutex` is only used for EGL calls, while `egl::ContextMutex`
implementations for GL calls. Because some EGL calls use Context,
explicit `egl::ContextMutex` lock is required. This is implemented by
generating "egl_context_mutex_autogen.h" header, and insertion of
`ANGLE_EGL_SCOPED_CONTEXT_LOCK()` macro before `ANGLE_EGL_VALIDATE()`
in each EGL entry point. Implementation in "egl_context_lock_impl.h"
returns lock for required APIs. Special cases of `egl::ContextMutex`
lock handled separately. `std::unique_lock<>` is not used for
performance reasons.
`egl::ContextMutex` explicitly locked when capturing EGL calls.
Fixes EGLImage problem:
e18240d136
Mark contexts as shared when importing EGL images.
Details:
- EGLImage inherits Context's mutex when created.
Mutex is used when the EGLImage accessed or destroyed.
- When EGLImage is used in Context with other `egl::ContextMutex`,
two mutexes are merged into one.
- After the mutex merge, Context Groups will remain separate,
but will not be able to run in parallel.
Fixes race when checking `context->isShared()` in the
`SCOPED_SHARE_CONTEXT_LOCK()` macro. One Context may start executing GL
call while not "Shared", but become "Shared" inside the call. New
(second) "Shared" Context may immediately start using GL and potentially
corrupt some "Shared" state.
Possible performance benefit: allows parallel execution in some cases,
when single `GlobalMutex` would block.
Important note:
Process of replacing the `SingleContextMutex` by
`SharedContextMutex<Mutex>` is not 100% safe. This mean that
original Context may still be using `SingleContextMutex` after
activating `SharedContextMutex<Mutex>`. However, this was always
the case before introduction of this CL. Old `Context::mShared`
member update was not synchronized in any way at all. In other
words, this solution does not 100% fix the original problem.
For 100% safe solution `SingleContextMutex` should not be used
(always pass `SharedContextMutex<Mutex>` to the `gl::Context`
constructor). See `lockAndActivateSharedContextMutex()` for more
details.
CL adds new build option:
angle_enable_shared_context_mutex = true
Behavior with other build options:
- When:
`angle_enable_shared_context_mutex` is disabled or
`angle_enable_share_context_lock` is disabled or
`angle_force_context_check_every_call` is enabled,
Contexts will always have `SingleContextMutex`, however it will be
only used in special cases. `SCOPED_SHARE_CONTEXT_LOCK()` will use
`GlobalMutex` when applicable.
- Otherwise, `SCOPED_SHARE_CONTEXT_LOCK()` will use `egl::ContextMutex`.
Some GFXBench "1080p Driver Overhead 2 Offscreen" performance numbers.
Tested on S906B (Samsung Galaxy S22+) on old ANGLE base:
807c94ea85
Capture/Replay: Adjust tests do adhere to capture limits
Each test result is an average frame number from 6 runs.
SingleContextMutex 6579 ( +0.13%)
(old) GetContextLock() (mShared is false) 6570
Forced `mShared = true` or NOT using `SingleContextMutex`.
SharedContextMutex<std::mutex> FORCE 5061 (-22.97%)
(old) GetContextLock() FORCE 4766 (-27.46%)
Bug: angleproject:6957
Bug: chromium:1336126
Change-Id: Idcd919f9d4bf482b9ae489bd8b4415ec96048e32
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4374545
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Updates the script to produce reasonably formatted code without
clang-format.
Autogen files moved to autogen/ sub-directories because clang-format
does not support per-file settings ;(
This allows to run this codegen very quickly
(~50ms on my machine)
Bug: angleproject:8193
Change-Id: Ie84282090d574ebb4debe3edcfd82f983f27a5ff
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4604578
Commit-Queue: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
I was having trouble using some GL/EGL loader generators because of some
errors in the XML definitions for ANGLE.
The first major problem is the content of the <ptype> tags. Let's refer
to the Khronos registry XML schema (which is annoyingly a PDF rather
than an xsd that we can test against, though I don't know if an xsd
would catch this anyway):
https://raw.githubusercontent.com/KhronosGroup/OpenGL-Registry/master/xml/readme.pdf
In section 12.4.2, "Contents of <param> tags" it states:
The <ptype> tag is optional, and contains text which is a valid type
name found in <type> tag, and indicates that this type must be
previously defined for the definition of the command to succeed.
Builtin C types, and any derived types which are expected to be
found in other header files, should not be wrapped in <ptype> tags
Note that the above is repeated for the contents of <proto> tags as
well.
The extension XML files currently have a bunch of <ptype> tags which
don't meet the expectations described above. The correct transformation
for them would be, for example:
<ptype>GLfloat *</ptype> -> <ptype>GLfloat</ptype> *
<ptype>void *</ptype> -> void *
<ptype>const char *</ptype> -> const char *
<ptype>EGLAttrib *</ptype> -> <ptype>EGLAttrib</ptype> *
The next issue is that some tags have some typos, such as "<pytpe>"
instead of "<ptype>". (Now *that* is something an .xsd would catch...)
The last issue is the use of the typename "GLvoid" which is not as
serious a problem. It is still defined in Khronos' gl.xml <types> block,
but Khronos no longer uses it in their XML registries. The comment for
the "GLvoid" type in their <types> block states:
<type comment="Not an actual GL type, though used in headers in the past">typedef void <name>GLvoid</name>;</type>
So we might as well replace those with just plain "void".
Anyway, long story short: to apply these transformations, I used Perl
regular expressions, and applied these expressions in order:
- Fix the tag misspellings:
s#<(/?)pytpe>#<\1ptype>#g
- Move the const qualifiers (if present) and pointer asterisk(s) (if
any) outside the <ptype> tag itself:
s#<ptype>(const )?([A-Za-z0-9]+)[ ]?(\*\*?)</ptype> #\1<ptype>\2</ptype> \3#g
- Replace "GLvoid", "char", and "void" inside ptype tags to normal
C types outside tags:
s#<ptype>(GLvoid|void|char)</ptype>#\1#g
Bug: angleproject:8190
Change-Id: Ib0bea79fecb7e714910b6e92124bb9f52994d0fb
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4603709
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
The name in the extension/require block did not match the name in the
enum specification block. This caused some EGL loader generators to fail
to run properly.
Bug: angleproject:8190
Change-Id: I6ce6e226121e7ea9aa611c7d331a8fd1bc83e55b
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4603708
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Commit-Queue: Kenneth Russell <kbr@chromium.org>
Collecting this data takes a significant amount of resources but we do
not actively use it at the moment.
Disable --split-shard-samples (will avoid separate calibration on each
shard)
Reduce samples to 6 (from default 10)
Bug: angleproject:7671
Change-Id: I87d45f21badb30ed44de9b9854c94fe7f67ecdc8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4605335
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Defines the interface between the test suite
(or an other TraceLibrary class user) and trace libraries.
TraceFunctions defines entry points for calls suite->trace, such as
SetupReplay() or SetBinaryDataDir().
TraceCallbacks defines entry points for calls trace->suite, for example
for loading .angledata.gz files.
These are set up via the exported SetupEntryPoints() call. Functions
like SetupReplay etc no longer need to be exported from the trace
library.
TraceInfo (parsed representation of the trace json) is moved to
trace_interface as is. This is convenient for further changes to the
fixture that will allow to easily move some of the captured parameters
to json.
This also moves Decompress functionality (and memory ownership) to test
suite entirely, which avoids Decompress/Delete callbacks - the trace
just calls LoadBinaryData via TraceCallbacks and TraceLibrary releases
the memory either on FinishReplay or in its destructor.
This should also take care of the memory leak described in
https://crrev.com/c/3858185
Bug: b/286072760
Change-Id: Ibc6f6f64156ad805b1917c8fc41a3b0d2c0d6375
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4594445
Reviewed-by: Amirali Abdolrashidi <abdolrashidi@google.com>
Commit-Queue: Roman Lavrov <romanl@google.com>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Now that chromium/base has rolled and switched the android_ndk_root to
the new android_toolchain directory, remove the stale Android NDK. Fix
roller scripts to no longer roll Android NDK and Android blueprint
generation can remove references to the removed sources.
Bug: chromium:1448383
Test: Verified build of ANGLE.
Change-Id: Iba8bfd8be9fd6bfb4f75f5d3a273411bd11f6b5e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4585389
Auto-Submit: Prashanth Swaminathan <prashanthsw@google.com>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Chromium is being updated to 'android_toolchain', which means the
'android_ndk' DEPS is no longer present. Remove it from the roller until
the transition is complete, then it can be removed from this script
entirely.
Bug: chromium:1448383
Change-Id: I0b515611a94f9aae5951655639a57ec5a9e7ffde
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4600111
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Prashanth Swaminathan <prashanthsw@google.com>
The Android NDK dependency is moving to a CIPD bucket to reduce the
checkout cost and to eventually move to NDK v25. This introduces the
NDK into an 'android_toolchain' directory. Following the roll of
chromium/base in this repository, a second change will delete the old
'android_ndk' checkout. As a result, the checkout size of this
repository will temporarily increase.
Bug: chromium:1448383
Test: Verified local builds of ANGLE.
Change-Id: Id2b7593270ae8d98e7353011dbc1b564da107786
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4585388
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Only changes the way we get auto_script inputs/outputs.
Before this CL, some of the scripts (depending on the shebang)
are run via vpython3 - which can take a few seconds. But the
inputs/outputs code generally doesn't require any unusual imports, so we
can just add little hacks to suppress those imports where needed when
an argument is given to the script.
Bug: angleproject:8184
Change-Id: Ib09a35b839318253fe7e913e24a756d2cb46dad1
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4585820
Commit-Queue: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
When a driver bug with dynamic state is encountered, it is hard to debug
which dynamic state exactly is causing an issue, due to the current
granularity of disabling all entire state from an extension. With this
change, every dynamic state gets its own ANGLE feature, and can be
toggled as necessary.
Disabling the supportsExtendedDynamicState* features implicitly
disables all dependent features.
Bug: b/285124778
Bug: b/275210062
Bug: fuchsia:107106
Bug: angleproject:5906
Change-Id: Ic291279872df2d0eb58618ff364ab118bdcc4a9f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4577553
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
This reverts commit ee64836f70 ,
relanding the patch stack described there.
Between patchsets 1 and 5:
- The shadow buffer allocation has been replaced with a multimap of
precisely-sized buffers, rather than rounding up buffer sizes.
- Garbage collection of shadow buffers is triggered in three situations:
- A certain number of context switches have occurred; this number
was hand-tuned to avoid GC every frame.
- A certain number of command buffer submissions has occurred; this
number was hand-tuned to GC no more often than every few seconds
on representative workloads.
- The total size of the allocated shadow buffers is more than 1 MB,
and either more than twice the size at the last garbage
collection, or 64 MB more than at the last garbage collection. In
this case, aggressive GC is performed in order to reclaim shadow
buffers more quickly.
Performance before and after these changes appears identical on
microbenchmarks. On one Figma test case, comparing GPU memory
allocated inside the BufferManager, peak consumption is decreased by
over 75%, and steady-state consumption decreases by over 88%.
Patchset 6 adds a needed workaround for a bug in the
AMDMTLBronzeDriver affecting uploads of client-side data, and
therefore some dEQP tests. It also streamlines the aggressive GC.
Bug: angleproject:7544
Change-Id: I81b061f0b33c27fa403527fa12d626f4e9c88ebe
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4497413
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Refactor the trace-replay EGLDisplay handling to allow
initializing the global EGLDisplay handle in the
InitializeReplay4() body. This included adding
support for eglGetCurrentDisplay() to the EGL-on-
WGL shim.
Test: angle_trace_tests --gtest_filter=infinity_ops
Bug: b/282725258
Change-Id: I2319fd9a35f8fb9c0a7f10547ca39f49ce402b8d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4546267
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Commit-Queue: Mark Łobodziński <mark@lunarg.com>
NVIDIA GPUs are in a very small number of Macs and we don't have have
adequate test coverage to properly support them.
Add the disable_metal_on_nvidia feature to control support for NVIDIA
at runtime. Also factor the support of GPU family 1 into a feature.
Bug: angleproject:8170
Change-Id: I160036d710cc9e278eb77e351a483b9f5b69e8ce
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4544659
Commit-Queue: Geoff Lang <geofflang@chromium.org>
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Banning glDelete* is extremely dangerous. It will almost definitely
cause memory leaks in client code, and it makes JS garbage collection
needlessly complex.
Instead, specify that PLS is implicity deactivated if the client deletes
anything that is attached to the current draw framebuffer during a PLS
rendering pass.
Bug: chromium:1421437
Change-Id: I3a18ee6b5d5567431e6fa3eccea58cb049845502
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4521436
Reviewed-by: Kenneth Russell <kbr@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Chris Dalton <chris@rive.app>
