Bug 62618 – [chromium] Compositor shader initialization is inefficient

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[James Robinson]

[chromium] Compositor shader initialization is inefficient

[James Robinson]

Created attachment 97061 [details]
Patch

[James Robinson]

On my linux z600 this reduces the time from start of compositor initialization to first swapbuffers on the gpu process from 125ms->73ms for a nearly empty page and from 240ms->190ms for maps.google.com.

[Vangelis Kokkevis]

Comment on attachment 97061 [details]
Patch

Looks good!

[James Robinson]

Ken or Stephen, mind do an official WebKit review?

[Vangelis Kokkevis]

Comment on attachment 97061 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=97061&action=review

> Source/WebCore/platform/graphics/chromium/LayerRendererChromium.cpp:1106
> +    if (!m_borderProgram->initialized()) {

This just in:  Is there a reason why you don't call initialize() when the program first gets created?

[James Robinson]

(In reply to comment #5)
> (From update of attachment 97061 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=97061&action=review
> 
> > Source/WebCore/platform/graphics/chromium/LayerRendererChromium.cpp:1106
> > +    if (!m_borderProgram->initialized()) {
> 
> This just in:  Is there a reason why you don't call initialize() when the program first gets created?

Yes, definitely.  initialize() queries uniform locations, which is synchronous and flushes the command queue.  Calling initialize() when the program is first created will block the renderer until the shader is compiled and linked.  By creating the commonly used shaders at compositor startup but not calling initialize() until draw time the GPU process has a reasonable chance to compile the shader while the compositor is doing software painting and uploading.  The benefit is easiest to see by comparing traces.

[Stephen White]

Comment on attachment 97061 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=97061&action=review

> Source/WebCore/ChangeLog:19
> +        release builds and force synchronous compilation/linking.

Just out of curiosity:  What about bad drivers or machines where we might accidentally exceed hardware limits?  Do we want to catch those in release builds in the wild and try to fall back to non-composited mode?  Or is this too hard to do gracefully now that they're lazily initialized, and we just rely on the blacklist?

[James Robinson]

If we want to check for failures then we should do it once at the end of initializing the shaders we want instead of after each program.  I kind of doubt that's necessary, though - we should be blacklisting cards that can't handle the compositor's shaders.

[Stephen White]

OK, looks good.  R=me

[WebKit Review Bot]

Comment on attachment 97061 [details]
Patch

Clearing flags on attachment: 97061

Committed r88835: <http://trac.webkit.org/changeset/88835>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.