Bug 230107 – [WebGL2, Safari 15 - iOS15] Problems with drawElements in some conditions

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

[Brendan Duncan]

Created attachment 437756 [details]
Repo test of a iOS15 WebGL2 problem

Testing Unity WebGL2 builds on iOS 15 Beta 8, there are draw calls being used by Unity's UI system that cause WebGL2 to go into a bad state. It stops rendering, takes over 5000ms to complete a frame, usually crashing the page before too long.

I narrowed it down to a complex shader being used by the Unity UI system, and a call to drawElements that causes things to go wrong. I attached a small Javascript reproduction of the issue. The test is a self contained HTML with embedded JS code with the minimal GL calls that trigger the issue. It doesn't render anything useful, it's just triggering the problem. The problem can be seen by the displayed frame rate dropping to ~5000ms.

The repo test runs correctly on MacOS Safari 15, and on Android mobiles. The issue only happens on iOS 15, tested on an iPhone XS and iPad.

In the repo test, there are three lines:
    gl.drawElements(4, 174, 5123, 0); // Original from Unity, BAD
    //gl.drawElements(4, 159, 5123, 0); // BAD
    //gl.drawElements(4, 158, 5123, 0); // GOOD

If I change the drawElements count to 158, the problem goes away. At count 159, the problem appears. 
In the real, non repo test, the shader and drawElements are generated from Unity, not manually authored.

[Kimmo Kinnunen]

I can confirm iPhone 12, WebGL via Metal: repros.

[Kimmo Kinnunen]

No repro on OpenGL.

[Kimmo Kinnunen]

Error during command buffer execution

[Radar WebKit Bug Importer]

<rdar://problem/82975755>

[Kenneth Russell]

Thanks so much Kimmo for investigating and confirming.

Do you think you might be able to take this bug since only someone from Apple can really debug it? Do you think it's something ANGLE's Metal backend is doing wrong and that's the cause of the command buffer execution error?

The vertex and element array buffers in this example are being allocated with DYNAMIC_DRAW. UNSIGNED_SHORT indices are being used. All of the data is zeroed out, so all of the triangles being drawn are degenerate. (All zero indices, all 0.0 vertices.)

[Brendan Duncan]

Thanks to both of you.

Please don't get hung up on the zero index and vertex buffers, and the resulting degenerate triangles. I just didn't include the array data to avoid including the giant arrays, since it still seemed to have the effect without the data. If the degenerate triangles are throwing off testing, I can include that data.

[Brendan Duncan]

I was wondering if there was any progress identifying the issue as it will be a significant problem for Unity WebGL builds running on iOS15.

[Kyle Piddington]

(In reply to Brendan Duncan from comment #7)
> I was wondering if there was any progress identifying the issue as it will
> be a significant problem for Unity WebGL builds running on iOS15.

Hey Brendan, 
Thank you for the ping on this. I'll have a chance to look this week on what can be causing our perf issue. Our submission issue is due to a page fault in the shader. Perhaps we're not allocating enough space for our index buffer?

[Kyle Piddington]

Created attachment 438868 [details]
Repo test of a iOS15 WebGL2 problem  -- Draw One Triangle

Local testing

[Kyle Piddington]

Created attachment 438875 [details]
Repo test of a iOS15 WebGL2 problem - Draw No Vertex Buffer

[Kyle Piddington]

Created attachment 438877 [details]
Repo test of a iOS15 WebGL2 problem - Draw Bigger Vertex Buffer

[Kyle Piddington]

From debugging:
Adjusting the vertex array from 16384 to 16385, or to smaller (144) seem to work,
In addition to adjusting the drawElements call from 158 to 159.

[Kyle Piddington]

(In reply to Kyle Piddington from comment #12)
> From debugging:
> Adjusting the vertex array from 16384 to 16385, or to smaller (144) seem to
> work

I misread this: This isn't the vertex array. It's the index array. 
I think something's gone wrong with allocating exactly 4k indices. How that relates to drawing less or more, I haven't figured out yet.

[Kyle Piddington]

(In reply to Kyle Piddington from comment #13)
> I think something's gone wrong with allocating exactly 4k indices. How that
> relates to drawing less or more, I haven't figured out yet.

And by 4k, I meant 16k. (0x4000, got my wires crossed)

[Kyle Piddington]

Issue appears to be in the provoking vertex index rewrite. I just spotted that the UI elements uses flat shading. Disabling index rewrite causes this to work.

[Kyle Piddington]

Created attachment 438905 [details]
Patch

[EWS Watchlist]

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

[Brendan Duncan]

This is great! Thank you Kyle!

[Kimmo Kinnunen]

Comment on attachment 438905 [details]
Patch

Looks good for what I understand.
I think we "guess" that `pipelineState.maxTotalThreadsPerThreadgroup >= 64`?


For obligatory nits, the first hunk is unnecessary and the second hunk you could have formatted with the command..

[Kyle Piddington]

Created attachment 438963 [details]
Patch

[Kenneth Russell]

Comment on attachment 438963 [details]
Patch

Great find and fix Kyle! I defer to Dean's earlier review.

[Kyle Piddington]

Created attachment 439094 [details]
Patch for landing

[EWS]

Committed r283014 (242079@main): <https://commits.webkit.org/242079@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 439094 [details].