[go: up one dir, main page]
Google Git
Sign in
chromium / angle / angle / refs/heads/chromium/6860
commitea86503c2a52c63871548703e7a02642fb5e1b6d[log] [tgz]
authorIgor Nazarov <i.nazarov@samsung.com>Wed Nov 20 17:47:49 2024
committerAngle LUCI CQ <angle-scoped@luci-project-accounts.iam.gserviceaccount.com>Tue Nov 26 00:44:23 2024
treede59081c290c73208c1ab12acdac99079075407f
parentb94d7853941f63adab6290449614828e1d70af50 [diff]
Vulkan: Remove vkAcquireNextImageKHR multi-threading support

Currently, it is not possible to call `TryAcquireNextImageUnlocked()`
from multiple threads. However, original implementation added
multi-threading support for future use.

Possible future use:
- First thread (where Surface is current) calls
  `eglPrepareSwapBuffersANGLE()` which will call
  `TryAcquireNextImageUnlocked()` in the unlocked tail call (without the
  share group lock).
- Other thread (where shared Context is current) calls some EGL/GLES
  API under the share group lock, that may cause calling
  `doDeferredAcquireNextImage()` on the Surface from the first thread.
  Calling this method may call `TryAcquireNextImageUnlocked()` under the
  share group lock, while it is also called from the first thread in the
  unlocked tail call. Calling `doDeferredAcquireNextImage()` may also
  cause swapchain recreation.

Taking into account above scenario, current implementation has following
bugs:
1. Possibility to recreate the swapchain from other thread, while first
   thread is going to or calling the `TryAcquireNextImageUnlocked()`
   function:
   a) Other thread may call `prepareForAcquireNextSwapchainImage()`
      because `NeedToProcessAcquireNextImageResult()` is still false
      until first thread finishes `TryAcquireNextImageUnlocked()` call.
      Also, checking `NeedToProcessAcquireNextImageResult()` from other
      thread is not thread safe.
   b) Other thread finished `TryAcquireNextImageUnlocked()` first, but
      with `VK_ERROR_OUT_OF_DATE_KHR` error. First thread still did not
      get the chance to call this function because of OS's thread
      scheduling delays. Other thread will set
      `needToAcquireNextSwapchainImage = true` and will start to
      recreate a swapchain. At this time, first thread will start
      executing `TryAcquireNextImageUnlocked()`, and because bool is
      true - it will actually perform ANI during recreate from other
      thread.
2. Possibility to call `TryAcquireNextImageUnlocked()` with old
   swapchain. This is similar to (1), but this time call is delayed
   after swapchain is recreated.

Since above scenario currently is not possible and the described future
scenario is unlikely to ever happen, instead of fixing above problems
this CL removes the multi-threading support to simplify the code and
make these bugs N/A.

Change removes word "try" from structures, members, and functions
because without multithreading there is no need for that and just adds
unnecessary complication.

It also removes most of the "share group lock" mentions because now this
information is irrelevant and may cause confusion. What is relevant is
that `AcquireNextImageUnlocked()` MUST only be called from a thread
where Surface is current and only CAN access members that is only ever
accessed from this thread (regardless if the lock is taken or not).

For example, if in the future `unlockedAcquireResult` will be accessed
from other thread but with the share group lock held, while
`AcquireNextImageUnlocked()` will still only be called from the current
thread - then this will be a race condition.

Bug: angleproject:42265346
Bug: angleproject:42266579
Change-Id: Ie9be408c0a3b3c1f37ec80727ce5ad2cb8932dad
Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/6018093
Reviewed-by: Shahbaz Youssefi <syoussefi@chromium.org>
Reviewed-by: Charlie Lao <cclao@google.com>
Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org>
2 files changed
tree: de59081c290c73208c1ab12acdac99079075407f
  1. android/
  2. build_overrides/
  3. doc/
  4. extensions/
  5. gni/
  6. include/
  7. infra/
  8. samples/
  9. scripts/
  10. src/
  11. third_party/
  12. tools/
  13. util/
  14. build
  15. buildtools
  16. testing
  17. .clang-format
  18. .git-blame-ignore-revs
  19. .gitattributes
  20. .gitignore
  21. .gitmodules
  22. .gn
  23. .style.yapf
  24. .vpython
  25. .vpython3
  26. .yapfignore
  27. additional_readme_paths.json
  28. Android.mk
  29. AUTHORS
  30. BUILD.gn
  31. codereview.settings
  32. CONTRIBUTORS
  33. DEPS
  34. DIR_METADATA
  35. dotfile_settings.gni
  36. LICENSE
  37. OWNERS
  38. PRESUBMIT.py
  39. README.chromium
  40. README.md
  41. WATCHLISTS
README.md

ANGLE - Almost Native Graphics Layer Engine

The goal of ANGLE is to allow users of multiple operating systems to seamlessly run WebGL and other OpenGL ES content by translating OpenGL ES API calls to one of the hardware-supported APIs available for that platform. ANGLE currently provides translation from OpenGL ES 2.0, 3.0 and 3.1 to Vulkan, desktop OpenGL, OpenGL ES, Direct3D 9, and Direct3D 11. Future plans include ES 3.2, translation to Metal and MacOS, Chrome OS, and Fuchsia support.

Level of OpenGL ES support via backing renderers

Direct3D 9Direct3D 11Desktop GLGL ESVulkanMetal
OpenGL ES 2.0completecompletecompletecompletecompletecomplete
OpenGL ES 3.0completecompletecompletecompletecomplete
OpenGL ES 3.1incompletecompletecompletecomplete
OpenGL ES 3.2in progressin progresscomplete

Additionally, OpenGL ES 1.1 is implemented in the front-end using OpenGL ES 3.0 features. This version of the specification is thus supported on all platforms specified above that support OpenGL ES 3.0 with known issues.

Platform support via backing renderers

Direct3D 9Direct3D 11Desktop GLGL ESVulkanMetal
Windowscompletecompletecompletecompletecomplete
Linuxcompletecomplete
Mac OS Xcompletecomplete [1]
iOScomplete [2]
Chrome OScompleteplanned
Androidcompletecomplete
GGP (Stadia)complete
Fuchsiacomplete

[1] Metal is supported on macOS 10.14+

[2] Metal is supported on iOS 12+

ANGLE v1.0.772 was certified compliant by passing the OpenGL ES 2.0.3 conformance tests in October 2011.

ANGLE has received the following certifications with the Vulkan backend:

  • OpenGL ES 2.0: ANGLE 2.1.0.d46e2fb1e341 (Nov, 2019)
  • OpenGL ES 3.0: ANGLE 2.1.0.f18ff947360d (Feb, 2020)
  • OpenGL ES 3.1: ANGLE 2.1.0.f5dace0f1e57 (Jul, 2020)
  • OpenGL ES 3.2: ANGLE 2.1.2.21688.59f158c1695f (Sept, 2023)

ANGLE also provides an implementation of the EGL 1.5 specification.

ANGLE is used as the default WebGL backend for both Google Chrome and Mozilla Firefox on Windows platforms. Chrome uses ANGLE for all graphics rendering on Windows, including the accelerated Canvas2D implementation and the Native Client sandbox environment.

Portions of the ANGLE shader compiler are used as a shader validator and translator by WebGL implementations across multiple platforms. It is used on Mac OS X, Linux, and in mobile variants of the browsers. Having one shader validator helps to ensure that a consistent set of GLSL ES shaders are accepted across browsers and platforms. The shader translator can be used to translate shaders to other shading languages, and to optionally apply shader modifications to work around bugs or quirks in the native graphics drivers. The translator targets Desktop GLSL, Vulkan GLSL, Direct3D HLSL, and even ESSL for native GLES2 platforms.

OpenCL Implementation

In addition to OpenGL ES, ANGLE also provides an optional OpenCL runtime built into the same output GLES lib.

This work/effort is currently work-in-progress/experimental.

This work provides the same benefits as the OpenGL implementation, having OpenCL APIs be translated to other HW-supported APIs available on that platform.

Level of OpenCL support via backing renderers

VulkanOpenCL
OpenCL 1.0in progressin progress
OpenCL 1.1in progressin progress
OpenCL 1.2in progressin progress
OpenCL 3.0in progressin progress

Each supported backing renderer above ends up being an OpenCL Platform for the user to choose from.

The OpenCL backend is a “passthrough” implementation which does not perform any API translation at all, instead forwarding API calls to other OpenCL driver(s)/implementation(s).

OpenCL also has an online compiler component to it that is used to compile OpenCL C source code at runtime (similarly to GLES and GLSL). Depending on the chosen backend(s), compiler implementations may vary. Below is a list of renderers and what OpenCL C compiler implementation is used for each:

  • Vulkan : clspv
  • OpenCL : Compiler is part of the native driver

Sources

ANGLE repository is hosted by Chromium project and can be browsed online or cloned with

git clone https://chromium.googlesource.com/angle/angle

Building

View the Dev setup instructions.

Contributing