Version 2 (modified by 4 years ago) ( diff ) | ,
---|
ANGLE and WebGL 2.0 in WebKit
by @dino (Apple), @James Darpinian (Google), @Kimmo Kinnunen (Apple) Slide Deck
WebKit has integrated the ANGLE project as its primary WebGL backend, significantly improving compatibility with other browsers, and enabling a conformant WebGL 2.0 in WebKit. This talk describes how ANGLE works from WebKit’s perspective, status of the project, and offers advice to other ports on switching to ANGLE.
kbr: Talks about background. Mentions that WebGL2 shipped in 2017 in Firefox and Chrome, but not on iOS. WebGL1 only gained traction with iOS implementation, so iOS support for WebGL2 is important
kbr: Some desire for WebGPU to be baseline, but requires more capable hardware (WebGL1 is the current baseline)
kbr: Implementation is not as simple as just exposing raw API, due to requirement for it to work the same across all platforms - requires lots of validation checks and such
kbr: ANGLE does this for us
kbr: ANGLE is an OpenGL ES implementation on top of other APIs: D3D, GL, GLES, Vulkan and Metal (last is very recent)
kbr: ANGLE exposes GLES 3.0, 3.1, 3.2 API and has built-in support for WebGL 1 and 2
kbr: Easiest path to WebGL2 in WebKit - implement WebGL via ANGLE, finish WebGL2 JS bindings - project started in June 2019
kbr: WebKit uses internal ANGLE API to avoid API collisions with system-level GL libraries
kbr: ANGLE has internal optimisation of GL state changes, giving big potential performance improvements
kbr: ANGLE updating in WebKit is largely automated, except for Xcode project file update
kbr: ANGLE has been improved due to work on its integration in WebKit
kbr: per-platform code is necessary to integrate with the browser compositor, video stack, etc. - we will discuss Mac and iOS
kbr: Explaining class hierarchy (see slides)
smfr: Some of this code is being heavily refactored due to the GPU process work
kbr: these code links may/will be obsoleted pretty soon - hopefully this presentation isn't negatively useful, but we'll try to keep it up-to-date
kbr: Video-to-webgl-texture performance is important - handled by GraphicsContextGLCVANGLE
kbr: With EGL, the context must be current only in one thread at a time - this restriction isn't there on iOS
kbr: Multi-threading problems exist in the WK1 execution model and care must be taken, these problems don't exist with the WK2 execution model
kbr: WebGL2 required updating lots of code that can interact with texture uploads, such as ImageBitmap creation, creating textures from DOM elements, etc. - this is done and tested
kbr: WebKit's WebGL2 implementation is passing over 98% of the conformance suite
kbr: WebGL1 under ANGLE also improved, but no numbers to hand
kbr: goal is 100% conformance on MacOS and iOS - remaining failures are mostly GPU-specific driver bugs that need workarounds
kbr: Lots of sites and demos are working well - we've been collaborating with partners, like Unity, to ensure this
kbr: We'd like all WebKit ports to adopt the ANGLE backend - especially Linux/embedded Linux and Windows
kbr: full ANGLE adoption would allow removal of USE(OPENGL) and USE(OPENGL_ES) #ifdefs, which would be a huge simplification
kbr: OffscreenCanvas support could use ANGLE via GPU process, or otherwise ANGLE would need more multi-threading support
Questions & Comments
clord: Why was the internal API exposure necessary for WebKit, but not for Chrome?
kbr: Chrome dynamically looks up ANGLE symbols so there's zero possibility of collision. To simplify the work and interaction with the WebKit build system, a static linking approach was used.
deanjackson: ANGLE will be dynamically linked into WebCore soon. Everything continues to work as it is, changes aren't required. We could use the Chromium model now, but it isn't urgent.
smfr: OffscreenCanvas, GPUProcess dependencies - do you think you'd disable support until GPUProcess could be used, or would you do the work to make ANGLE usable across multiple threads?
kbr: We'd do the work. Talks about the synchronisation, sounds like a tractable problem.
smfr: If it depended on GPUProcess, it may impose requirements for newer OS versions as GPUProcess may not be supported on older OS versions
kbr: Further reassurance about commitment to getting it to work with OffscreenCanvas on as many platform/OS combinations as possible