This commit adds a check to ensure that the GL backend's functions
have been properly initialized. This may happen with third party
build toolchains, like vcpkg, which reimplement parts of the
existing build system.
Bug: angleproject:8195
Change-Id: Iaca2200a563c5049d90acad57785088c94b4e580
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4614645
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Implements the first part (FrameCapture) of the proposal
go/frame-capture-and-interpreter-testing
Adds a basic test (CapturedTest) with a few frames. This test gets
captured by capture_tests.py into a temporary directory and the
resulting files are diff'ed with the files under expected/
A diff fails the test. When capture changes, the workflow would be to
run the command indicated by the error message in the test which will
overwrite the files with new ones so that they can be added to the CL.
Example test failure on capture change:
https://chromium-swarm.appspot.com/task?id=62b5f4034527c610
when testing https://crrev.com/c/4598046/3
Tests in CI: https://screenshot.googleplex.com/77o8vZVuj8AbFRj
Also adds a "angle_capture_tests_trace" lib with the trace just to test
that this capture also builds, the lib is not currently loaded by
anything.
Bug: b/286067106
Change-Id: I7d5f6eed088d84f9e3eb8a72b24b1d92515fff38
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4545408
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Commit-Queue: Roman Lavrov <romanl@google.com>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Added `gl::Context::isContextMutexStateConsistent()` method. This method
is primarily used to check if "SharedContextMutex" activation worked
successfully. It is automatically called in the updated
`ScopedContextMutexLock` before unlocking. This is to catch possible
errors using ASSERT during normal ANGLE operation in applications and
tests.
The `ScopedContextMutexLock` is now also used instead of the
`std::lock_guard<egl::ContextMutex>` in the `SCOPED_SHARE_CONTEXT_LOCK`.
No performance regression observed.
Important note: `lockAndActivateSharedContextMutex()` is NOT 100% safe
regardless of the `kActivationDelayMicro` value, so `ASSERT` may still
fail. However, failure does not necessary mean that there will be an
undefined behavior, it means that UB might happen.
Bug: angleproject:6957
Bug: chromium:1336126
Change-Id: Iee7357fede0d37fa315fe2cc7d27a4e30a304194
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4610227
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Igor Nazarov <i.nazarov@samsung.com>
Removes scripts/code_generation_hashes/Test_spec_JSON.json
Instead, run codegen in --verify-only mode and compare content.
This run during presubmits and is fast (~0.2s in my tests)
Similar to https://crrev.com/c/4604579
With this, should be able to auto-resolve conflicts in
infra/specs/angle.json
Also testing/buildbot/mixins.pyl
seems to have had hashes routinely updated by autorolls.
Bug: angleproject:8193
Change-Id: Ic1a657dbf464e6f4a8066ea8c5e18297e27a3b4c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4605467
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
Auto-Submit: Roman Lavrov <romanl@google.com>
Commit-Queue: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
There are multiple issues with dynamic states on
ARM. Previously we have disabled individual dynamic
state that had issues, but it turns out some dynamic
states need to be enabled/disabled together for tests
traces to work correctly.
Disabling the supportsExtendedDynamicState until
all the issues are addressed.
Bug: b/287318431
Bug: b/285196249
Bug: b/286224923
Change-Id: If2f039b8392898e1e42b5da6b1277e82818a1b1a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4615995
Reviewed-by: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Remove deqp khr gles31 test suppression on Pixel 6
that are no longer failing.
Remove the suppression of below tests:
KHR-GLES31.core.texture_buffer.texture_buffer_texture_buffer_range
Restrict the suppression of below tests on
swiftshader, windows nvidia vulkan, and pixel6 vulkan
KHR-GLES31.core.texture_border_clamp.Texture2DDC16Linear
KHR-GLES31.core.texture_border_clamp.Texture2DDC32FLinear
Remove the suppression of below tests
KHR-GLES31.core.shader_storage_buffer_object.advanced-unsizedArrayLength*
Restrict the suppression of below tests on swiftshader
KHR-GLES31.core.arrays_of_arrays.ConstructorsAndUnsizedDeclConstructors1
KHR-GLES31.core.arrays_of_arrays.ConstructorsAndUnsizedDeclConstructorSizing1
Bug: angleproject:3573
Bug: angleproject:5978
Bug: angleproject:4107
Bug: angleproject:4300
Bug: angleproject:4108
Bug: angleproject:4188
Bug: angleproject:4190
Bug: angleproject:4240
Bug: angleproject:6295
Bug: b/224537784
Change-Id: I2c4d67ad3c50381ece4ed6241657b79402c91d3d
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4606543
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Remove deqp khr gles3 test suppression on Pixel 6
that are no longer failing.
Restrict the suppression of below tests on Pixel4 Vulkan
KHR-GLES3.packed_depth_stencil.clear_buffer.depth32f_stencil8
Restrict the suppression of below tests on
NVIDIA Vulkan and Android Vulkan
KHR-GLES3.packed_pixels.varied_rectangle.*
Restrict the suppression of below tests on
NVIDIA Vulkan and Android Vulkan
KHR-GLES3.packed_pixels.pbo_rectangle.r8_snorm
KHR-GLES3.packed_pixels.pbo_rectangle.rg8_snorm
KHR-GLES3.packed_pixels.pbo_rectangle.rgba8_snorm
KHR-GLES3.packed_pixels.rectangle.r8_snorm
KHR-GLES3.packed_pixels.rectangle.rg8_snorm
KHR-GLES3.packed_pixels.rectangle.rgba8_snorm
Bug: angleproject:3683
Bug: angleproject:6678
Bug: angleproject:8048
Bug: b/224537784
Change-Id: Id24591e3bc21fa263fa64d3bd812d82209b8c5fd
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4606542
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Remove the deqp gles31 test suppression on Pixel 6
that are no longer failing.
Below tests no longer fails on win-test bot, remove them
from the expectation file:
dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.48
dEQP-GLES31.functional.ssbo.layout.random.all_shared_buffer.36
Restrict the suppression of below tests on NVIDIA Vulkan
dEQP-GLES31.functional.image_load_store.3d.*single_layer
Restrict the suppression of below tests on Pixel4 Vulkan
dEQP-GLES31.functional.copy_image.non_compressed.viewclass_32_bits.rgba8_snorm_rgb10_a2*
dEQP-GLES31.functional.copy_image.non_compressed.viewclass_32_bits.rgba8_snorm_rgb9_e5*
Remove the suppression of below tests on Android Vulkan
dEQP-GLES31.functional.stencil_texturing.misc.base_level
Remove the suppression of below tests on Pixel6
dEQP-GLES31.functional.shaders.linkage.es31.tessellation.varying.rules.internal_different_precision
Bug: b/224537784
Bug: angleproject:3445
Bug: angleproject:6021
Bug: angleproject:4080
Bug: angleproject:5277
Bug: angleproject:7488
Change-Id: I9baff33ade443d2ad28d1bc7a1333e0c672942c5
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4606541
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Remove deqp gles3 test suppression on Pixel 6
that are no longer failing.
Undefined behaviors in below test should have been
addressed by the upstream change in VK-GL-CTS:
5d286e0dae
Remove the suppression of them:
dEQP-GLES3.functional.shaders.operator.unary_operator.minus.lowp_uvec4_vertex
dEQP-GLES3.functional.shaders.operator.unary_operator.minus.mediump_uvec4_vertex
Restrict the suppression of below tests on
NVIDIA and MAC
dEQP-GLES3.functional.fbo.completeness.renderable.*.r8_snorm
dEQP-GLES3.functional.fbo.completeness.renderable.*.rg8_snorm
dEQP-GLES3.functional.fbo.completeness.renderable.*.rgba8_snorm
Bug: b/224537784
Bug: angleproject:1101
Bug: angleproject:6214
Bug: angleproject:8048
Change-Id: Ic227be3e08b85f9f812171faafbbb1d421e9c30a
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4606540
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
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>
Remove the override test31Context so that
1) we can run deqp test suites on Pixel devices
with the same configuration as Android CTS test
runner.
2) those deqp tests that require a GLES 3.2
context will not be skipped and can execute on
devices that supports GLES 3.2.
Since the deqp test runner overrides the feature
exposeNonConformantExtensionsAndVersions with "true" value,
a context is created regardless of whether the device supports
GLES 3.2. However, not all of the devices are GLES 3.2
conformant, we will suppress those tests that
are failing on non-conformant devices.
Bug: b/224537784
Bug: angleproject:3687
Bug: angleproject:3688
Bug: angleproject:6678
Change-Id: I2a549537bdbb2c0356fcccaa96291229c699ed0f
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4559445
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Roman Lavrov <romanl@google.com>
Global settings can be set by adb command and hence clearing the all
global settings values are not ideal. Previously ANGLE apk triggers a
clear when device boot is completed because we register the receiver and
immediately trigger the callback. However, that causes race condition as
our testing infra will set up the ANGLE per-application override to run
tests on top of ANGLE apk. This patch removes that trigger.
Bug: b/285594264
Test: Verify per-application override is no longer cleared
Change-Id: Ic10703b72593cee7f067570a523f668553047ae2
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4611447
Reviewed-by: Solti Ho <solti@google.com>
Commit-Queue: Yuxin Hu <yuxinhu@google.com>
Auto-Submit: Peiyong Lin <lpy@google.com>
Typically, the format used for data uploads and downloads as well as the
storage format are consistent. That is unfortunately not the case for
GL_RGBX8_ANGLE where data uploads are through 3-byte RGB pixels while
downloads are through 4-byte RGBX pixels. This change swaps out RGBX
for RGBA on the read pixels path.
Test credit of Jason Macnak <natsu@google.com>
Bug: b/246008627
Test: atest CtsSkQPTestCases
Change-Id: I531ebd8318bf4fe5ac09c623068b790a7e301428
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4608488
Reviewed-by: Jason Macnak <natsu@google.com>
Auto-Submit: Shahbaz Youssefi <syoussefi@chromium.org>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Geoff Lang <geofflang@chromium.org>
Commit-Queue: Geoff Lang <geofflang@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>
There appears to be a bug in the interaction of CFI and
relative vtables. On armv9 it results in a crash with SIGILL
when loading traces.
Since we can't overwrite the flags used to control this
just assert that it is correct in GN args.
To avoid the assert, add the following to your GN args:
arm_control_flow_integrity = "none"
Test: Build and run traces on armv9 devices
Bug: b/278955379
Bug: chromium:1441148
Change-Id: I71bf93dca9bd15d6c66ad2a7223d9bbd0c54392e
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4602027
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: Cody Northrop <cnorthrop@google.com>
Reviewed-by: Yuly Novikov <ynovikov@chromium.org>
In this change, the shader interface variables are given SPIR-V ids by
the compiler before SPIR-V generation. Those ids are made available
through the ShaderVariable interface.
The transformer does not yet rely on this information. A follow up
change will rework the backend's name->info map and the transformer to
directly use ids instead of names.
Bug: angleproject:7220
Change-Id: Ic0a62681d4bcf3ed171c39c3ecd83e438ea068c8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4600609
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Roman Lavrov <romanl@google.com>
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Instead of passing in gl_Position etc built-in names and then find their
index by looking at OpMemberName instructions, this change has the
front-end create a bitset of active gl_PerVertex members. The SPIR-V
transformer then directly uses this information to trim gl_PerVertex.
Bug: angleproject:7220
Change-Id: I5c3d56784801abb310d09d98d9c82c9e6e019de8
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4600608
Reviewed-by: Yuxin Hu <yuxinhu@google.com>
Reviewed-by: Roman Lavrov <romanl@google.com>
Commit-Queue: 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>
DmaBufImageSiblingVkLinux::initWithFormat is used to fallback like:
- mutable format + srgb
- mutable format + unorm
- non-mutable srgb
- non-mutable unorm
However, it never fallbacks since GetFormatModifierProperties bails.So
this change has made it non-fatal to allow fallback behavior.
Meanwhile, this change updates the fallback order to use unorm as actual
format first to favor most common scenarios.
Bug: b/277798516
Change-Id: I60283590d85b27d55010cb2f5a2cc13d4df1ac9c
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/4603208
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Auto-Submit: Yiwei Zhang <zzyiwei@chromium.org>
Reviewed-by: Romaric Jodin <rjodin@chromium.org>
