Bug 215630 – Safari 14: Graphics is distorted when playing online games (https://cs-online.club/en/servers)

• Component: WebGL
• Status: RESOLVED FIXED

[Dean Jackson]

* TITLE:
graphics is distorted when playing online games

* USER REPORTED AREA:
Safari

* MACHINE WAS RUNNING BUILD:
19F101

* DESCRIPTION:
Graphics is distorted or not properly displayed

Try to play via this link:   https://cs-online.club/en/servers

* OTHER INFORMATION:

Text input language
English

* MACHINE MODEL:
iMac14,2

[Dean Jackson]

I can reproduce with tip-of-tree builds.

[Dean Jackson]

Note: the game takes a long long time to load the first time. Use one of the "Play" buttons on the right side.

[Dean Jackson]

<rdar://problem/66417801>

[Kenneth Russell]

Created attachment 406823 [details]
Screenshot of bad rendering

[Kenneth Russell]

This renders incorrectly in Chrome Canary, too, using ANGLE as the WebGL backend:
/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --user-data-dir=/tmp/t1 --use-cmd-decoder=passthrough

It seems likely there's some graphics driver bug workaround not yet in ANGLE which needs to be put in place.

[Dean Jackson]

(In reply to Kenneth Russell from comment #5)

> It seems likely there's some graphics driver bug workaround not yet in ANGLE
> which needs to be put in place.

I was using an iMac Pro. The original report was also an AMD device.

What did you try?

[Dean Jackson]

I'm a bit confused as to what is going on with the page. On good frames the page simply does:

bufferSubData
clear
drawArrays (the lines)
drawArrays (the nodes)

On the frames that produce black, there is also a pass that:

createFramebuffer
createTexture
texImage2D
framebufferTexture2D
createRenderbuffer
viewport
scissor
createProgram
adds shaders and links
drawArrays
readPixels

[Dean Jackson]

The page is compiled, so it is hard to work out what is going on, but it seems to be coming from a call to three.js readRenderTargetPixels.

[James Darpinian]

I'm seeing just a whole lot of texture corruption. I also see texture corruption in most of the tests marked "AMD driver bug" in https://docs.google.com/spreadsheets/d/1qxoX-pd3ZqP9R95UdPzYjwqaJCSGi4Ix5H4Ix7mlZEM/edit?pli=1#gid=570815629

I think Ken is right, if we fix those tests then I bet it'll fix this. The one I planned to look at first is https://www.khronos.org/registry/webgl/sdk/tests/deqp/functional/gles3/pixelbufferobject.html

[Dean Jackson]

Arrg. Ignore my last few comments. Wrong bug.

[James Darpinian]

But I'm not going to look into it tomorrow because it's performance review season, so feel free to look first.

[Kenneth Russell]

Both James and I are a bit swamped this week and would appreciate any help figuring out which driver bug needs to be worked around to pass more of the failing conformance tests.

One approach might be to search through this file:
https://source.chromium.org/chromium/chromium/src/+/master:gpu/config/gpu_driver_bug_list.json?q=gpu_driver_bug_list.json

for:
  "type": "macosx"

then launch Chrome from the command line disabling each of those workarounds in turn:

/Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary --user-data-dir=/tmp/t1 --use-cmd-decoder=validating --clamp_texture_base_level_and_max_level=0

(--use-cmd-decoder=passthrough switches to the ANGLE backend)

and see which one causes those tests to break, and/or this site to start rendering incorrectly.

[Kenneth Russell]

Note I also wondered specifically whether the workaround:
use_intermediary_for_copy_texture_image

which references http://crbug.com/581777 might be related.

[James Darpinian]

I tried running Canary with --use-cmd-decoder=validating --disable-gpu-driver-bug-workarounds and it doesn't reproduce the issue on cs-online.club, so I don't think it's related to any of our driver bug workaround. The issue *does* occur when using ANGLE as a backend for the validating command decoder (--use-cmd-decoder=validating --use-gl=angle --use-angle=gl).

Also I just noticed that https://www.khronos.org/registry/webgl/sdk/tests/deqp/functional/gles3/pixelbufferobject.html fails in stable Chrome with the validating command decoder as well, so it may not be the same bug after all.

[Kimmo Kinnunen]

MacBookPro11,4 Intel Iris
Can repro failure on:
WebKit r265849 defaults (i.e. USE_ANGLE=1)
Chrome Canary 86.0.4238.2 with passthrough

Can repro success on:
Safari Version 13.1.2 (15609.3.5.1.3) (catalina?)
Chrome Canary 86.0.4238.2 with defaults (i.e. validating cmd buffer)

The common webgl 1.0.4 conformance tests that pass on "success" set but fail on "failure" set is "conformance/textures/misc/gl-teximage.html". This is maybe a good candidate test to fix first.

webgl-conformance-webkit-angle
 "failures": [
    "conformance/canvas/to-data-url-test.html",
    "conformance/context/constants-and-properties.html",
    "conformance/context/context-lost-restored.html",
    "conformance/context/incorrect-context-object-behaviour.html",
    "conformance/extensions/ext-float-blend.html",
    "conformance/extensions/oes-texture-half-float.html",
    "conformance/extensions/webgl-draw-buffers.html",
    "conformance/glsl/misc/fragcolor-fragdata-invariant.html",
    "conformance/programs/program-handling.html",
    "conformance/programs/program-test.html",
    "conformance/reading/read-pixels-test.html",
    "conformance/rendering/blending.html",
    "conformance/rendering/rendering-stencil-large-viewport.html",
    "conformance/textures/misc/gl-teximage.html",
    "conformance/textures/misc/texture-corner-case-videos.html",
    "conformance/textures/misc/texture-npot-video.html",
  ],
  
webgl-conformance-chrome-passthrough
  "failures": [
    "conformance/buffers/buffer-data-and-buffer-sub-data.html",
    "conformance/context/methods.html",
    "conformance/extensions/oes-texture-half-float.html",
    "conformance/glsl/misc/fragcolor-fragdata-invariant.html",
    "conformance/offscreencanvas/methods.html",
    "conformance/offscreencanvas/methods-worker.html",
    "conformance/programs/program-handling.html",
    "conformance/rendering/blending.html",
    "conformance/textures/misc/gl-teximage.html",
    "conformance/textures/webgl_canvas/tex-2d-rgba-rgba-unsigned_byte.html",
    "conformance/textures/webgl_canvas/tex-2d-rgba-rgba-unsigned_short_4_4_4_4.html",
    "conformance/textures/webgl_canvas/tex-2d-rgba-rgba-unsigned_short_5_5_5_1.html",
  ],

[Kimmo Kinnunen]

gl-teximage.html case is where the null parameter of texImage2D should (presumably) set the alpha to 1 but seems to set it to 0.

[Kenneth Russell]

Good investigation Kimmo!

Even if the code path that makes Chrome's validating command decoder work for this game isn't covered under one of the driver bug workarounds, I think it's still likely that working around the remaining driver bugs that affect WebGL 2.0 conformance will also fix this game. Maybe some of the needed workarounds were hard-coded.

James has triaged these failures in the WebGL 2.0 Implementation Logistics spreadsheet (just shared with you). If we find a couple of the most likely candidate driver bugs and try implementing workarounds in ANGLE, this game might start working.

I have a feeling this might still be related to either needing to reset the texture's base level in some situations (Chromium's reset_base_mipmap_level_before_texstorage and reset_teximage2d_base_level workarounds) or IOSurface- and CopyTexImage2D-related issues (use_intermediary_for_copy_texture_image - though that might have been fixed in newer OS releases).

[Kimmo Kinnunen]

I've been working on this but no solution yet. I've tried a bit to replicate the generatemipmap+min filter mode workaround non-ANGLE webkit had, and I've tried to disable base-level manipulating workarounds in current ANGLE. Neither seem to make a difference.
 
Next I will try to apply some known workarounds related to mipmap generation and texture base level.

[Kimmo Kinnunen]

ANGLE bug:
https://bugs.chromium.org/p/angleproject/issues/detail?id=5006

[Kimmo Kinnunen]

Created attachment 407669 [details]
Patch

[EWS Watchlist]

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

[Kenneth Russell]

Comment on attachment 407669 [details]
Patch

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

Awesome work Kimmo tracking this down! How did you manage to find it just from the large app?

This is a crucial fix - just raised the priority of the ANGLE bug you filed. It would be ideal if you could upload your fix to ANGLE's Gerrit instance before this lands - there's a great deal of automated testing hooked up there, including the dEQP tests, which will help guard against any regressions.

Again, amazing work!

> Source/ThirdParty/ANGLE/ChangeLog:13
> +        https://bugs.webkit.org/show_bug.cgi?id=215630

Did you use "Tools/Scripts/webkit-patch upload" to generate this patch and ChangeLog? It should have properly formatted the ChangeLog automatically (note the first "OOPS!" above - the second is replaced by the commit queue). "Change-Id" shouldn't show up here. (If you're trying to upload the patch to both WebKit and the ANGLE project from within WebKit's ANGLE snapshot, I would recommend you make a second checkout of the ANGLE project instead.)

[Kimmo Kinnunen]

Created attachment 407875 [details]
Patch

[Dean Jackson]

Comment on attachment 407875 [details]
Patch

r+ing this so it can land in WebKit. The ANGLE team are currently looking at it upstream.

[EWS]

Committed r266539: <https://trac.webkit.org/changeset/266539>

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

[Kimmo Kinnunen]

*** Bug 217381 has been marked as a duplicate of this bug. ***