[chromium] Compositor shader initialization is inefficient
Created attachment 97061 [details] Patch
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.
Comment on attachment 97061 [details] Patch Looks good!
Ken or Stephen, mind do an official WebKit review?
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?
(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.
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?
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.
OK, looks good. R=me
Comment on attachment 97061 [details] Patch Clearing flags on attachment: 97061 Committed r88835: <http://trac.webkit.org/changeset/88835>
All reviewed patches have been landed. Closing bug.