Bug 98308 – Optimize texture-complete checks

• Status: RESOLVED
• Resolution: FIXED
• Component: WebGL

[Gregg Tavares]

Right now on every WebGL draw call, WebKit goes through a loop checking that all textures are renderable in WebGLRenderingContext::handleNPOTTextures

That's not a small or simple loop. For example on one of my machines, m_texureUnits is 160

The suggested optimization is to track the number of unrenderable textures. If that number is 0 the loop and be skipped.

Tracking requires updating the count anytime a texture is created, deleted, or it's state is modified.

[Radar WebKit Bug Importer]

<rdar://problem/12439489>

[Brent Fulgham]

Created attachment 271044 [details]
Patch

[Brent Fulgham]

Initial patch. Needs some additional work.

[Kenneth Russell]

Note: you may want to look at the patches in http://crbug.com/570453 . Some of the validation was pushed to lower levels, which may not be possible in WebKit, but if it is, a tremendous amount of code can be deleted from WebKit's WebGL implementation.

[Build Bot]

Comment on attachment 271044 [details]
Patch

Attachment 271044 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.webkit.org/results/812933

New failing tests:
fast/canvas/webgl/tex-image-webgl.html
fast/canvas/webgl/premultiplyalpha-test.html
webgl/1.0.3/conformance/extensions/oes-texture-float-linear.html
fast/canvas/webgl/tex-sub-image-cube-maps.html

[Build Bot]

Created attachment 271045 [details]
Archive of layout-test-results from ews102 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews102  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 271044 [details]
Patch

Attachment 271044 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/812942

New failing tests:
fast/canvas/webgl/tex-image-webgl.html
fast/canvas/webgl/premultiplyalpha-test.html
webgl/1.0.3/conformance/extensions/oes-texture-float-linear.html
fast/canvas/webgl/tex-sub-image-cube-maps.html

[Build Bot]

Created attachment 271046 [details]
Archive of layout-test-results from ews104 for mac-yosemite-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews104  Port: mac-yosemite-wk2  Platform: Mac OS X 10.10.5

[Build Bot]

Comment on attachment 271044 [details]
Patch

Attachment 271044 [details] did not pass mac-debug-ews (mac):
Output: http://webkit-queues.webkit.org/results/812929

New failing tests:
fast/canvas/webgl/tex-image-webgl.html
fast/canvas/webgl/premultiplyalpha-test.html
webgl/1.0.3/conformance/extensions/oes-texture-float-linear.html
fast/canvas/webgl/tex-sub-image-cube-maps.html

[Build Bot]

Created attachment 271047 [details]
Archive of layout-test-results from ews114 for mac-yosemite

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews114  Port: mac-yosemite  Platform: Mac OS X 10.10.5

[Alex Christensen]

(In reply to comment #4)
> Note: you may want to look at the patches in http://crbug.com/570453 . Some
> of the validation was pushed to lower levels, which may not be possible in
> WebKit, but if it is, a tremendous amount of code can be deleted from
> WebKit's WebGL implementation.

Thanks for the tip, Kenneth!  Is this because Chromium is now using ANGLE's desktop GL or GLES backend, and the validation is being done inside ANGLE?  Does Chromium use ANGLE for all drawing?  Right now, WebKit just uses ANGLE for GLSL validation (and drawing to a pbuffer on Windows, IIRC), but we might want to look into using ANGLE for more.

[Brent Fulgham]

(In reply to comment #11)
> (In reply to comment #4)
> > Note: you may want to look at the patches in http://crbug.com/570453 . Some
> > of the validation was pushed to lower levels, which may not be possible in
> > WebKit, but if it is, a tremendous amount of code can be deleted from
> > WebKit's WebGL implementation.
> 
> Thanks for the tip, Kenneth!  Is this because Chromium is now using ANGLE's
> desktop GL or GLES backend, and the validation is being done inside ANGLE? 
> Does Chromium use ANGLE for all drawing?  Right now, WebKit just uses ANGLE
> for GLSL validation (and drawing to a pbuffer on Windows, IIRC), but we
> might want to look into using ANGLE for more.

No -- they have a different architecture with a set of command buffers that talk to the GPU. We don't really have a similar concept in WebKit's architecture.

[Brent Fulgham]

Created attachment 271064 [details]
Patch

[Dean Jackson]

(In reply to comment #12)

> > Thanks for the tip, Kenneth!  Is this because Chromium is now using ANGLE's
> > desktop GL or GLES backend, and the validation is being done inside ANGLE? 
> > Does Chromium use ANGLE for all drawing?  Right now, WebKit just uses ANGLE
> > for GLSL validation (and drawing to a pbuffer on Windows, IIRC), but we
> > might want to look into using ANGLE for more.
> 
> No -- they have a different architecture with a set of command buffers that
> talk to the GPU. We don't really have a similar concept in WebKit's
> architecture.

They are planning to use ANGLE for all drawing and rely on that for validation.

[Dean Jackson]

Comment on attachment 271064 [details]
Patch

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

> Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp:967
> +        if (textureUnit.texture2DBinding && textureUnit.texture2DBinding->needToUseBlackTexture(extensions()))

This would be shorter as if (texture && texture->needToUseBlackTexture(extensions()))

> Source/WebCore/html/canvas/WebGLRenderingContextBase.cpp:974
> +        if (textureUnit.textureCubeMapBinding && textureUnit.textureCubeMapBinding->needToUseBlackTexture(extensions()))

Same here.

> Source/WebCore/html/canvas/WebGLRenderingContextBase.h:435
> +    WebGLTexture::TextureExtensionFlag extensions() const;

I think this should be called textureExtensions() or textureExtentionsFlags()

[Kenneth Russell]

(In reply to comment #14)
> (In reply to comment #12)
> 
> > > Thanks for the tip, Kenneth!  Is this because Chromium is now using ANGLE's
> > > desktop GL or GLES backend, and the validation is being done inside ANGLE? 
> > > Does Chromium use ANGLE for all drawing?  Right now, WebKit just uses ANGLE
> > > for GLSL validation (and drawing to a pbuffer on Windows, IIRC), but we
> > > might want to look into using ANGLE for more.
> > 
> > No -- they have a different architecture with a set of command buffers that
> > talk to the GPU. We don't really have a similar concept in WebKit's
> > architecture.
> 
> They are planning to use ANGLE for all drawing and rely on that for
> validation.

That's correct. Right now it's Chrome's command buffer which is providing the majority of the texture validation. Soon it will be ANGLE.

Still, if you assume you are hosted on a conformant ES 3.0 implementation, you can probably reduce the amount of texture validation WebKit performs. It only needs to implement the differences between WebGL and OpenGL ES 3.0 (like the ability to dynamically enable extensions like EXT_color_buffer_float, OES_texture_float_linear, etc.) -- and how that affects texture completeness.

[Brent Fulgham]

This change does seem to provide a small win. I ran the Unity WebGL benchmark a number of times with and without the patch on my laptop:

Without patch:  46335
With patch:     48546

So, we can hand-wave that this is roughly a 5% win. There's probably opportunity for other improvements.

[Brent Fulgham]

Committed r196460: <http://trac.webkit.org/changeset/196460>