[Webkit-unassigned] [Bug 240392] New: [GTK][WPE] Current-context enforcement in ANGLE is expensive

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri May 13 11:32:35 PDT 2022


https://bugs.webkit.org/show_bug.cgi?id=240392

            Bug ID: 240392
           Summary: [GTK][WPE] Current-context enforcement in ANGLE is
                    expensive
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: New Bugs
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: zan at falconsigh.net
            Blocks: 237649

For basically every WebGL entrypoint, the ANGLE context is enforced to be current for the executing thread.

There's at this point in time the smart check to test whether the current context is already the one that we are using, through comparing against EGL_GetCurrentContext() return value. Only when not equal do we go on to call EGL_MakeCurrent().

Even the check is still expensive because it does an inefficient job of loading from thread-local storage. Because it's called on every WebGL entrypoint this becomes quite visible on profiles and a considerable amount of time is spent here. I can provide receipts later.

ANGLE is internally using the `thread_local` specifier on the data structure holding the current-context value. Mesa doesn't suffer from this, and is using the `__thread` specifier, along with the `tls_model("initial-exec")` attribute. This needs confirmation on what the differentiator exactly is, after that it should be possible to decide what to change and where to do it.


Referenced Bugs:

https://bugs.webkit.org/show_bug.cgi?id=237649
[Bug 237649] [Meta][Linux] Adoption of DMABuf as a reference buffer sharing mechanism
-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20220513/8d04a235/attachment-0001.htm>


More information about the webkit-unassigned mailing list