Bug 212251

This Unity game (emscriptened to wasm) is not working on iOS with the ANGLE backend. Steps to repro (on iOS): 1. Load https://tiny.vision/demos/TinyRacing/Wasm/TinyRacing.html After loading the page, the screen is blank and no sound is playing. 2. Tap anywhere on the screen and you’ll hear a count down sound. 3. Press on the lower right of the screen and you’ll hear the sound of an engine accelerating.

We've fixed a lot of bugs that we noticed when comparing the behaviour of this game with and without ANGLE. - OES_texture_float and OES_texture_half_float extensions - OES_texture_half_float_linear extensions - PVRTC compressed texture support So we're now at a point where there is very little that can be directly detected by the game.

Created attachment 400017 [details] Wasm + JS builds

Created attachment 400018 [details] WebGL Traces Attaching two traces of every WebGL call. This allows you to compare side by side (assuming you have a good diff tool)

Created attachment 400020 [details] Tracing TinyRacing.js Attaching a modified version of TinyRacing.js that traces all WebGL calls. The differences are: - the game stops after 10 frames - the WebGL context is replaced by a Proxy object that logs every function call, parameters and return value - The trace can be downloaded by executing "WebKitWebGLTrace.downloadTrace()" in a JS console. (I also run a tool over the trace to replace numbers with the WebGL enums, but that's not necessary)

Oh, the attached WithANGLE trace was taken with a compiled version of WebKit that intentionally does not expose ASTC, ATC, ETC and ETC1 compressed textures in order to minimize the difference from the working version. Other minor differences: - the working version erroneously exposed OES_texture_float_linear. It never actually worked. As far as I can tell from the logs, it was never used. - the ANGLE backend exposes EXT_color_buffer_half_float, but the same failure happens even without that - This could be unrelated, but the working version logs a few warnings to the console "checkFramebufferStatus: attachment type is not correct for attachment". These do not show up in the trace.

I'll live blog myself going through the diffs of the traces. - Starts with the minor diffs I mentioned above - The SHADING_LANGUAGE_VERSION string is slightly different. - The game does a lot of feature testing up front. The first difference is when testing texture_52 (16x16 RGB8 UNSIGNED_BYTE), where both builds throw an error, but INVALID_VALUE vs INVALID_OPERATION so probably not detected. - This happens with texture_54 too (16x16 RGB8UI UNSIGNED_BYTE). And a couple more times. - Oooh. Here's something that looks suspicious..... texImage2D(TEXTURE_2D, 0, DEPTH_COMPONENT, 16, 16, 0, DEPTH_COMPONENT, UNSIGNED_SHORT, null) produces an error on the ANGLE backend, but not on the old backend. (texture_73, just created)

Same with texImage2D(TEXTURE_2D, 0, DEPTH_STENCIL, 16, 16, 0, DEPTH_STENCIL, UNSIGNED_INT_24_8, null)

Support for the WEBGL_depth_texture extension on iOS was just fixed in Bug 212271; unfortunately, the game still fails to load.

Created attachment 400087 [details] WithANGLE2.log Updating trace WithANGLE2.log after bug 212271

Next significant diff is texImage2D(TEXTURE_2D, 0, SRGB, 16, 16, 0, SRGB, UNSIGNED_BYTE, pixels) which is failing on ANGLE This is bug: https://bugs.webkit.org/show_bug.cgi?id=212277 Then another with SRGB_ALPHA, which is the same bug. After that is a failure when calling generateMipmap(TEXTURE_2D) with the following: let tex = gl.createTexture(); gl.bindTexture(TEXTURE_2D, tex); texImage2D(TEXTURE_2D, 0, RGBA, 16, 16, 0, RGBA, FLOAT, new Float32Array(1024)); texImage2D(TEXTURE_2D, 1, RGBA, 8, 8, 0, RGBA, FLOAT, new Float32Array(256)); texImage2D(TEXTURE_2D, 2, RGBA, 4, 4, 0, RGBA, FLOAT, new Float32Array(64)); texImage2D(TEXTURE_2D, 3, RGBA, 2, 2, 0, RGBA, FLOAT, new Float32Array(16)); texImage2D(TEXTURE_2D, 4, RGBA, 1, 1, 0, RGBA, FLOAT, new Float32Array(4)); generateMipmaps();

getAttribLocation(program, "a_position") -> 2 with the ANGLE backend, and 1 without it. Shader source code was: VERTEX #define centroid #define flat #define noperspective #define smooth precision highp float; attribute highp vec4 a_color0; attribute highp vec4 a_color1; attribute highp vec3 a_position; attribute highp vec2 a_texcoord0; varying highp vec4 v_color0; varying highp vec4 v_color1; varying highp vec2 v_texcoord0; uniform highp mat4 u_modelViewProj; void main () { highp vec4 tmpvar_1; tmpvar_1.w = 1.0; tmpvar_1.xyz = a_position; gl_Position = (u_modelViewProj * tmpvar_1); v_texcoord0 = a_texcoord0; v_color0 = a_color0; v_color1 = a_color1; } FRAGMENT #define centroid #define flat #define noperspective #define smooth precision mediump float; varying highp vec4 v_color0; varying highp vec4 v_color1; varying highp vec2 v_texcoord0; uniform sampler2D s_texColor; void main () { lowp vec4 tmpvar_1; tmpvar_1 = mix (v_color1, v_color0, texture2D (s_texColor, v_texcoord0).xxxx); if ((tmpvar_1.w < 0.003921569)) { discard; }; gl_FragColor = tmpvar_1; }

And then the ANGLE backend causing the app to look up the bgfx_clear_color uniform locations (which are not used without ANGLE)

Created attachment 400092 [details] Example shaders

With the attached shaders... Non-ANGLE looks for: s_texAlbedoOpacity u_light_pos0 u_smoothness_params ... ANGLE looks for: u_view u_model ... It fetches some WebGLActiveInfos before that. I should check they are the same.

Dean, per #c12 above related to generateMipmaps() failing - can you extract that into a small HTML file and file a separate bug about that? ANGLE's supposed to be emulating those unsized internal formats internally in order to make them renderable, and maybe there's a bug in that code. Not sure where the conformance tests would be catching that.

I think the uniform differences are not important. I bet the ActiveInfos are providing the difference in where it looks up the uniforms. If you skip past that and get to setting the uniform values, the only difference is the uniformLocation, so it seems the draw parameters are identical.

Created attachment 400096 [details] generateMipmap test Reduced test that calls generateMipmap()

Hmm. The generateMipmap test fails the generateMipmap call in top-of-tree Chrome (Canary) with INVALID_OPERATION, too.

(In reply to Kenneth Russell from comment #20) > Hmm. The generateMipmap test fails the generateMipmap call in top-of-tree > Chrome (Canary) with INVALID_OPERATION, too. Yeah. I forgot to comment here. This test produces INVALID_OPERATION after generateMipmap() on macOS/iOS with ANGLE + Chrome. But on iOS without ANGLE it does not produce the error. This makes me think it was an existing bug that has been fixed, and thus unlikely to be the cause of TinyRacing.

And it didn't fail on macOS without ANGLE too, so it looks like it was a bug in the old validation code.

Hmmm... maybe my reduction is wrong.

Filed https://bugs.chromium.org/p/angleproject/issues/detail?id=4656 on ANGLE, because I believe it should be failing the validation in generateMipmaps, rather than it coming from the GL driver.

My next step is going to be to trace literally everything and write an app to play it back step by step. The issue with that is going to be that the current trace is done in json, and that's too verbose for the larger buffers. So that would mean some other form of serialization.

Looks like this might have been a compositing issue, which explains why tracing wasn't getting me anywhere.

I'd like to add a test to ensure this type of content doesn't break. I wonder if it is acceptable to put a copy of https://tiny.vision/demos/Tiny3D/Wasm/Tiny3D.html into our test suite. The source code is https://github.com/Unity-Technologies/ProjectTinySamples

This was in fact fixed by https://bugs.webkit.org/show_bug.cgi?id=212277 I'm not sure why I didn't notice that earlier.