Open Bug 1341913 Opened 5 years ago Updated 2 months ago

Stop looking up GLContext symbols for every new window

Categories

(Core :: Graphics, defect, P3)

defect

Tracking

()

Tracking Status
firefox54 --- affected

People

(Reporter: mstange, Unassigned)

Details

(Keywords: perf, Whiteboard: [gfx-noted][qf:p3])

Attachments

(1 file)

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?
Priority: -- → P3
Whiteboard: [gfx-noted]
Depends on: 1345756
No longer depends on: 1345756
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.
Blocks: 1370131
Nominating for Quantum Flow: This only affects Mac, but the fix is probably really simple and would have great impact.
Whiteboard: [gfx-noted] → [gfx-noted][qf]
jgilbert is there any reason we can't have a global mSymbols table instead of a per context one?
Flags: needinfo?(jgilbert)
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.
(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.
Flags: needinfo?(jgilbert)
(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?
Flags: needinfo?(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.
Flags: needinfo?(jgilbert)
(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.
Flags: needinfo?(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.
Flags: needinfo?(jgilbert)
(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.
Whiteboard: [gfx-noted][qf] → [gfx-noted][qf:p3]
Depends on: 1385403
No longer depends on: 1385403
No longer blocks: 1370131
You need to log in before you can comment on or make changes to this bug.