Bug 205483 – [WebGL] Enable ANGLE by default for Cocoa platforms

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

[Dean Jackson]

[WebGL] Enable ANGLE by default for Cocoa platforms (except simulator)

[Radar WebKit Bug Importer]

<rdar://problem/58097701>

[Dean Jackson]

rdar://56925821

[Dean Jackson]

Created attachment 386169 [details]
Patch

[Alexey Proskuryakov]

Poor simulator! What is the plan for testing iOS port?

[Dean Jackson]

(In reply to Alexey Proskuryakov from comment #4)
> Poor simulator! What is the plan for testing iOS port?

Google are planning on allowing ANGLE to take a platform GL texture in place of an IOSurface.

[Dean Jackson]

Created attachment 386219 [details]
Patch

[EWS Watchlist]

Note that there are important steps to take when updating ANGLE. See http://trac.webkit.org/wiki/UpdatingANGLE

[Alexey Proskuryakov]

Does the simulator not support something needed from IOSurface in this particular case?

See bug 203026, Turn on IOSurface support in the iOS Simulator.

[Alexey Proskuryakov]

Comment on attachment 386219 [details]
Patch

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

> LayoutTests/webgl/2.0.0/conformance/renderbuffers/framebuffer-object-attachment-expected.txt:13
> +[ 10: FAIL ] gl.checkFramebufferStatus(gl.FRAMEBUFFER) returned 36061

I haven't nearly reviewed much of the patch, but I scrolled around enough to find one regression. That would be a problem with zero regression policy.

[Dean Jackson]

Created attachment 386222 [details]
Patch

[Dean Jackson]

Comment on attachment 386219 [details]
Patch

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

>> LayoutTests/webgl/2.0.0/conformance/renderbuffers/framebuffer-object-attachment-expected.txt:13
>> +[ 10: FAIL ] gl.checkFramebufferStatus(gl.FRAMEBUFFER) returned 36061
> 
> I haven't nearly reviewed much of the patch, but I scrolled around enough to find one regression. That would be a problem with zero regression policy.

There are some regressions, but there are many more progressions - so we've decided it is a net win.

(Also, in this case, it is a regression in WebGL 2 which is not enabled by default)

[Kenneth Russell]

(In reply to Alexey Proskuryakov from comment #8)
> Does the simulator not support something needed from IOSurface in this
> particular case?
> 
> See bug 203026, Turn on IOSurface support in the iOS Simulator.

Ah - I hadn't noticed that!

I'll try building for the iOS Simulator with the ANGLE/project.pbxproj build fix in this patch and see whether the IOSurface presentation path works.

[Alexey Proskuryakov]

Awesome!

There could be more things disabled in WebKit on Simulator that can/should be enabled now.

[Justin Fan]

Comment on attachment 386222 [details]
Patch

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

> LayoutTests/fast/canvas/webgl/array-bounds-clamping-expected.txt:1
>   Checks that array access in a shader can not read out of bounds

Why was this test left in but other fast/canvas tests removed?

[Dean Jackson]

Created attachment 386272 [details]
Patch

[Dean Jackson]

Created attachment 386274 [details]
Patch

[Dean Jackson]

Comment on attachment 386222 [details]
Patch

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

>> LayoutTests/fast/canvas/webgl/array-bounds-clamping-expected.txt:1
>>   Checks that array access in a shader can not read out of bounds
> 
> Why was this test left in but other fast/canvas tests removed?

This isn't in the WebGL conformance suite.

[Dean Jackson]

(In reply to Kenneth Russell from comment #12)
> (In reply to Alexey Proskuryakov from comment #8)
> > Does the simulator not support something needed from IOSurface in this
> > particular case?
> > 
> > See bug 203026, Turn on IOSurface support in the iOS Simulator.
> 
> Ah - I hadn't noticed that!
> 
> I'll try building for the iOS Simulator with the ANGLE/project.pbxproj build
> fix in this patch and see whether the IOSurface presentation path works.

Nope! It's not that the simulator doesn't have IOSurface, it's that

@interface EAGLContext(IOSurface)
- (BOOL)texImageIOSurface:(IOSurfaceRef)ioSurface target:(NSUInteger)target internalFormat:(NSUInteger)internalFormat width:(uint32_t)width height:(uint32_t)height format:(NSUInteger)format type:(NSUInteger)type plane:(uint32_t)plane NS_AVAILABLE_IOS(11_0);
@end

... is not implemented.

[Kenneth Russell]

(In reply to Dean Jackson from comment #18)
> (In reply to Kenneth Russell from comment #12)
> > (In reply to Alexey Proskuryakov from comment #8)
> > > Does the simulator not support something needed from IOSurface in this
> > > particular case?
> > > 
> > > See bug 203026, Turn on IOSurface support in the iOS Simulator.
> > 
> > Ah - I hadn't noticed that!
> > 
> > I'll try building for the iOS Simulator with the ANGLE/project.pbxproj build
> > fix in this patch and see whether the IOSurface presentation path works.
> 
> Nope! It's not that the simulator doesn't have IOSurface, it's that
> 
> @interface EAGLContext(IOSurface)
> - (BOOL)texImageIOSurface:(IOSurfaceRef)ioSurface target:(NSUInteger)target
> internalFormat:(NSUInteger)internalFormat width:(uint32_t)width
> height:(uint32_t)height format:(NSUInteger)format type:(NSUInteger)type
> plane:(uint32_t)plane NS_AVAILABLE_IOS(11_0);
> @end
> 
> ... is not implemented.

Thanks - I see that now, trying to enable that code path in ANGLE. I'll work on writing a (slow) emulation path for that in ANGLE and hopefully the WebKit-side code can work unmodified.

[Dean Jackson]

Weirdly, on this dual GPU device (MBP15), as soon as DumpRenderTree launches the machine swaps to the high-power GPU. This happens before the WebGL context is even created. Doesn't happen when running MiniBrowser with a WK1 window.

[Dean Jackson]

I'm trying to replicate the crash shown on the bots in WK1. It's not happening on this device when using the AMD chip in WK1, nor when using the Intel chip in WK2.

[Dean Jackson]

Actually, WebKitTestRunner triggers the high-power GPU too! MuxProbe says that the WindowServer and WebKitTestRunner/DumpRenderTree are the "bad" apps.

And it doesn't matter if it is a WebGL test or not.

[Dean Jackson]

https://bugs.webkit.org/show_bug.cgi?id=205546

[Dean Jackson]

Created attachment 386420 [details]
EWS test

[Dean Jackson]

Created attachment 386453 [details]
EWS test 2

[Dean Jackson]

Created attachment 386455 [details]
EWS test 3

[Dean Jackson]

Created attachment 386459 [details]
EWS test 4

[Dean Jackson]

Created attachment 386464 [details]
EWS test 5

[Dean Jackson]

Committed r253926: <https://trac.webkit.org/changeset/253926>

[Alexey Proskuryakov]

This patch adds many new expectations with "FAIL", but at least some of those are simply because those tests were marked as failing overall. Can you post a list of true known regressions, if there are any, and ideally file bugs for them?

[Dean Jackson]

Reverted in r254014

[Kenneth Russell]

Tracking down, and finding a fix or workaround for, the flakiness introduced with the ANGLE backend is our team's top priority.

At this point ANGLE has iOS Simulator support. Adjusting the summary.

[Justin Fan]

<rdar://problem/56925821>

[Dean Jackson]

Committed r256784: <https://trac.webkit.org/changeset/256784>