| commit | 2a42e887afc0aa4a863ff2fb67f9163ebceedb90 | [log] [tgz] |
|---|---|---|
| author | Shahbaz Youssefi <syoussefi@chromium.org> | Wed Oct 22 14:23:10 2025 |
| committer | Angle LUCI CQ <angle-scoped@luci-project-accounts.iam.gserviceaccount.com> | Wed Nov 05 17:05:00 2025 |
| tree | 68fee60c08945a43cc8bf974915390f46b5afb31 | |
| parent | be1fae49c38b837f9fe6c07cdabb43c4eb1ab0c0 [diff] |
Translator: Implement an IR The ANGLE compiler parses GLSL ES shaders and produces an Abstract Syntax Tree (AST). The use of AST is deceptively simple, as the structure of this representation always matches the equivalent text representation. This simplicity can make the compiler initially more approachable. However, as compiler research, modern compiler best practices, and our own experiences with the ANGLE compiler have shown, ASTs are harder to analyze and transform. For example: * Struct definitions may be in a number of surprising places in GLSL, such as a function’s return type. Reflecting this fact in the AST makes it tricky to apply transformations to the struct. * The inability to include arbitrary blocks of code in many locations such as inside an `if` condition turns simple transformations (such as caching an expression with a side effect inside a temporary variable) into complex ones with many corner cases. Instead, modern compilers include an Internal Representation (IR) that is potentially far removed from the textual syntax of the language. This comes with numerous benefits, such as the freedom to simplify and rearrange type definitions, the flexibility of instruction flow structure, etc, which in turn make more complex operations (such as dead-code elimination) less burdensome. In some projects, IRs also allow the compiler to handle multiple textual formats (otherwise known as front-ends). While generating an IR from text is typically not complicated, one possibly challenging aspect of IRs is going back to a textual representation if needed (such as generating glsl, msl or hlsl in the case of ANGLE), as the textual representation includes restrictions that do not exist in the IR. Given the number of bugs (security or otherwise) that constantly affect ANGLE, there is a need for an IR to finally modernize this codebase. The new WGSL backend for the translator is plagued with the same complications that the SPIR-V generator has faced (such as lack of ability to write to a swizzle expression), with extremely complicated or in some cases no clear way of implementing them in the AST, so an IR would simplify/unblock that work. Finally, some needed optimizations (such as cross-stage dead-code elimination) are needed for the ANGLE-for-Android project, but are extremely difficult to do with the AST. It’s time the translator was written to be based on an IR. ANGLE implements its own IR instead of reusing existing ones, such as SPIR-V, mesa's NIR, or Tint's IR, because: * It can be simpler e.g. compared to SPIR-V's highly flexible branching * It can be tailored to ESSL e.g. compared to Tint's IR * It can be in complete control e.g. compared to mesa's NIR This change implements the following: * GLSL->IR generation during parse * IR transformation utilities, debug dump, documentation (see src/compiler/translator/ir/doc/README.md) * An "astify" transformation that makes the IR suitable for AST and text-based output generation * IR->AST generation after parse The current AST generation during parse is still maintained because: * It's used by validation, but that will ultimately be made unnecessary after the following point is no longer needed. * It's simpler to keep the AST generation while the no-IR path is still supported. With the rountrip through IR, a dozen transformations that try to make the AST more malleable are made unnecessary. However, at this point when the IR is enabled, the overhead of creating it is present, while the transformations are still complex and based on the AST. The IR is disabled until almost all transformations are ported and at least SPIR-V generation is done directly from the IR. To enable the IR, set `angle_ir = true` in `args.gn`. Nearly all tests pass with the IR enabled, though a few failures remain to be diagnosed. One particular follow up fix is to port our compiler unittests to end2end tests: * They assume too much about the internals of the compiler, which is completely overhauled now * The validation is too simplistic, where often transformation bugs are discovered only after trying to use the shader in a draw call (where multiple backends actually give the translator output to the native driver/compiler) Bug: angleproject:349994211 Change-Id: I2ce917bf956d40af4545473b4a9068cf295878be Reviewed-on: https://chromium-review.googlesource.com/c/angle/angle/+/5898761 Reviewed-by: Geoff Lang <geofflang@chromium.org> Commit-Queue: Shahbaz Youssefi <syoussefi@chromium.org> Reviewed-by: Matthew Denton <mpdenton@chromium.org>
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.
| Direct3D 9 | Direct3D 11 | Desktop GL | GL ES | Vulkan | Metal | |
|---|---|---|---|---|---|---|
| OpenGL ES 2.0 | complete | complete | complete | complete | complete | complete |
| OpenGL ES 3.0 | complete | complete | complete | complete | complete | |
| OpenGL ES 3.1 | incomplete | complete | complete | complete | ||
| OpenGL ES 3.2 | in progress | in progress | complete |
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.
| Direct3D 9 | Direct3D 11 | Desktop GL | GL ES | Vulkan | Metal | WebGPU | |
|---|---|---|---|---|---|---|---|
| Windows | complete | complete | complete | complete | complete | ||
| Linux | complete | complete | |||||
| Mac OS X | complete | complete [1] | |||||
| iOS | complete [2] | ||||||
| Chrome OS | complete | planned | |||||
| Android | complete | complete | |||||
| Fuchsia | complete |
[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:
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.
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.
| Vulkan | OpenCL | |
|---|---|---|
| OpenCL 1.0 | in progress | in progress |
| OpenCL 1.1 | in progress | in progress |
| OpenCL 1.2 | in progress | in progress |
| OpenCL 3.0 | in progress | in 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 : clspvOpenCL : Compiler is part of the native driverANGLE repository is hosted by Chromium project and can be browsed online or cloned with
git clone https://chromium.googlesource.com/angle/angle
View the Dev setup instructions.
Join our Google group to keep up to date.
Join us on Slack in the #angle channel. You can follow the instructions on the Chromium developer page for the steps to join the Slack channel. For Googlers, please follow the instructions on this document to use your google or chromium email to join the Slack channel.
File bugs in the issue tracker (preferably with an isolated test-case).
Choose an ANGLE branch to track in your own project.
Read ANGLE development documentation.
Become a code contributor.
Use ANGLE's coding standard.
Learn how to build ANGLE for Chromium development.
Get help on debugging ANGLE.
Go through ANGLE's orientation and sift through issues. If you decide to take on any task, write a comment so you can get in touch with us, and more importantly, set yourself as the “owner” of the bug. This avoids having multiple people accidentally working on the same issue.
Read about WebGL on the Khronos WebGL Wiki.
Learn about the internals of ANGLE:
Read design docs on the Vulkan back-end
Read about ANGLE's testing infrastructure
View information on ANGLE's supported extensions
If you use ANGLE in your own project, we'd love to hear about it!