Changes between Initial Version and Version 1 of AngleforWebGL


Ignore:
Timestamp:
Jan 5, 2021 2:35:09 PM (21 months ago)
Author:
Jon Davis
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • AngleforWebGL

    v1 v1  
     1''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
     2
     3''kbr:'' Some desire for WebGPU to be baseline, but requires more capable hardware (WebGL1 is the current baseline)
     4
     5''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
     6
     7''kbr:'' ANGLE does this for us
     8
     9''kbr:'' ANGLE is an OpenGL ES implementation on top of other ''APIs:'' D3D, GL, GLES, Vulkan and Metal (last is very recent)
     10
     11''kbr:'' ANGLE exposes GLES 3.0, 3.1, 3.2 API and has built-in support for WebGL 1 and 2
     12
     13''kbr:'' Easiest path to WebGL2 in WebKit - implement WebGL via ANGLE, finish WebGL2 JS bindings - project started in June 2019
     14
     15''kbr:'' WebKit uses internal ANGLE API to avoid API collisions with system-level GL libraries
     16
     17''kbr:'' ANGLE has internal optimisation of GL state changes, giving big potential performance improvements
     18
     19''kbr:'' ANGLE updating in WebKit is largely automated, except for Xcode project file update
     20
     21''kbr:'' ANGLE has been improved due to work on its integration in WebKit
     22
     23''kbr:'' per-platform code is necessary to integrate with the browser compositor, video stack, etc. - we will discuss Mac and iOS
     24
     25''kbr:'' Explaining class hierarchy (see slides)
     26
     27''smfr:'' Some of this code is being heavily refactored due to the GPU process work
     28
     29''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
     30
     31''kbr:'' Video-to-webgl-texture performance is important - handled by GraphicsContextGLCVANGLE
     32
     33''kbr:'' With EGL, the context must be current only in one thread at a time - this restriction isn't there on iOS
     34
     35''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
     36
     37''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
     38
     39''kbr:'' WebKit's WebGL2 implementation is passing over 98% of the conformance suite
     40
     41''kbr:'' WebGL1 under ANGLE also improved, but no numbers to hand
     42
     43''kbr:'' goal is 100% conformance on MacOS and iOS - remaining failures are mostly GPU-specific driver bugs that need workarounds
     44
     45''kbr:'' Lots of sites and demos are working well - we've been collaborating with partners, like Unity, to ensure this
     46
     47''kbr:'' We'd like all WebKit ports to adopt the ANGLE backend - especially Linux/embedded Linux and Windows
     48
     49''kbr:'' full ANGLE adoption would allow removal of USE(OPENGL) and USE(OPENGL_ES) #ifdefs, which would be a huge simplification
     50
     51''kbr:'' OffscreenCanvas support could use ANGLE via GPU process, or otherwise ANGLE would need more multi-threading support
     52
     53== Questions & Comments ==
     54
     55''clord:'' Why was the internal API exposure necessary for WebKit, but not for Chrome?
     56
     57''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.
     58
     59''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.
     60
     61''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?
     62
     63''kbr:'' We'd do the work. Talks about the synchronisation, sounds like a tractable problem.
     64
     65''smfr:'' If it depended on GPUProcess, it may impose requirements for newer OS versions as GPUProcess may not be supported on older OS versions
     66
     67''kbr:'' Further reassurance about commitment to getting it to work with OffscreenCanvas on as many platform/OS combinations as possible