1341913 - Stop looking up GLContext symbols for every new window

Status: NEW

(Core :: Graphics, defect, P3)

Description

[Markus Stange [:mstange]]

Whenever you open a new window on Mac, we create a new GLContext, which reads GL symbols, see https://perfht.ml/2l1gFSc .

We should stop doing this for every window. We only need it once.
Can multiple GLContext instances share their symbol table?

Comment 1

[Markus Stange [:mstange]]

On my machine, fixing this would shave off 40ms on each new window.

This bug will also affect panels of remote WebExtensions (bug 1190679) because those use OMTC through the OpenGL compositor.

Comment 2

[Markus Stange [:mstange]]

Nominating for Quantum Flow: This only affects Mac, but the fix is probably really simple and would have great impact.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

jgilbert is there any reason we can't have a global mSymbols table instead of a per context one?

Comment 4

[Markus Stange [:mstange]]

Attachment: Bug 1341913 - Proof of concept.

Review commit: https://reviewboard.mozilla.org/r/154312/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/154312/

Comment 5

[Markus Stange [:mstange]]

This patch compiles and works. The big remaining piece on the compositor in terms of new window creation overhead is now just shader recompilitation, bug 1370885.

This patch drops a few consistency checks - we don't zero out symbols if we fail to look up a symbol, we don't zero out symbols on GLContext destruction (so we no longer have checks that a GLContext isn't used after it's marked as destroyed), and we don't deal with the fact that calling InitWithPrefix with a different prefix might need to look up different symbols.

Comment 6

[Kelsey Gilbert [:jgilbert]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #3)
> jgilbert is there any reason we can't have a global mSymbols table instead
> of a per context one?

Different profiles and versions can have different symbols. We can coalesce symbols for similar contexts, but not universally.

We also need to ensure we support different drivers/backends. Right now, we can have both ANGLE and native GL loaded on Windows. Having a single global symbol table breaks this support.

Comment 7

[Jeff Muizelaar [:jrmuizel]]

(In reply to Jeff Gilbert [:jgilbert] from comment #6)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #3)
> > jgilbert is there any reason we can't have a global mSymbols table instead
> > of a per context one?
> 
> Different profiles and versions can have different symbols. We can coalesce
> symbols for similar contexts, but not universally.

In what situations does this happen? How do we specify the profile/version when looking up the symbols?

Comment 8

[Kelsey Gilbert [:jgilbert]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #7)
> (In reply to Jeff Gilbert [:jgilbert] from comment #6)
> > (In reply to Jeff Muizelaar [:jrmuizel] from comment #3)
> > > jgilbert is there any reason we can't have a global mSymbols table instead
> > > of a per context one?
> > 
> > Different profiles and versions can have different symbols. We can coalesce
> > symbols for similar contexts, but not universally.
> 
> In what situations does this happen? How do we specify the profile/version
> when looking up the symbols?

A decent proxy is to hash by GL_RENDERER and GL_VERSION.
The specifics of profile and driver requests are very backend-specific, but we shouldn't need to know about it directly, since the uniqueness of GL_RENDERER+GL_VERSION should take care of this.

Comment 9

[Jeff Muizelaar [:jrmuizel]]

(In reply to Jeff Gilbert [:jgilbert] from comment #8)
> (In reply to Jeff Muizelaar [:jrmuizel] from comment #7)
> > (In reply to Jeff Gilbert [:jgilbert] from comment #6)
> > > (In reply to Jeff Muizelaar [:jrmuizel] from comment #3)
> > > > jgilbert is there any reason we can't have a global mSymbols table instead
> > > > of a per context one?
> > > 
> > > Different profiles and versions can have different symbols. We can coalesce
> > > symbols for similar contexts, but not universally.
> > 
> > In what situations does this happen? How do we specify the profile/version
> > when looking up the symbols?
> 
> A decent proxy is to hash by GL_RENDERER and GL_VERSION.
> The specifics of profile and driver requests are very backend-specific, but
> we shouldn't need to know about it directly, since the uniqueness of
> GL_RENDERER+GL_VERSION should take care of this.

No sorry, I meant what mechanism do we use to get different symbol lookup results depending on the profile/version?
None of wgl/egl/xglGetProcAddress take a version or any other kind of state.

Comment 10

[Kelsey Gilbert [:jgilbert]]

WGL certainly warns that addresses may be context-dependent. The way we handle extension/core function coalescing also breaks on core-vs-compat profiles, or just different versioned core profiles.

Also different backends (WGL vs EGL) certainly will provide different addresses.

Comment 11

[Jeff Muizelaar [:jrmuizel]]

(In reply to Jeff Gilbert [:jgilbert] from comment #10)
> WGL certainly warns that addresses may be context-dependent. The way we
> handle extension/core function coalescing also breaks on core-vs-compat
> profiles, or just different versioned core profiles.

Ah, I see. It uses the current context.