(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.
Does the simulator not support something needed from IOSurface in this particular case?
See bug 203026, Turn on IOSurface support in the iOS Simulator.
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.
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)
(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.
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.
(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.
(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.
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.
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.
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.
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?
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.
2019-12-19 17:44 PST, Dean Jackson
2019-12-20 09:43 PST, Dean Jackson
2019-12-20 09:56 PST, Dean Jackson
2019-12-20 15:55 PST, Dean Jackson
2019-12-20 16:45 PST, Dean Jackson
2019-12-26 12:08 PST, Dean Jackson
2019-12-27 13:28 PST, Dean Jackson
2019-12-27 14:00 PST, Dean Jackson
2019-12-27 16:41 PST, Dean Jackson
2019-12-28 00:15 PST, Dean Jackson