* 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
I can reproduce with tip-of-tree builds.
Note: the game takes a long long time to load the first time. Use one of the "Play" buttons on the right side.
<rdar://problem/66417801>
Created attachment 406823 [details] Screenshot of bad rendering
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.
(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?
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
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.
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
Arrg. Ignore my last few comments. Wrong bug.
But I'm not going to look into it tomorrow because it's performance review season, so feel free to look first.
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.
Note I also wondered specifically whether the workaround: use_intermediary_for_copy_texture_image which references http://crbug.com/581777 might be related.
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.
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", ],
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.
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).
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.
ANGLE bug: https://bugs.chromium.org/p/angleproject/issues/detail?id=5006
Created attachment 407669 [details] Patch
Note that there are important steps to take when updating ANGLE. See http://trac.webkit.org/wiki/UpdatingANGLE
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.)
Created attachment 407875 [details] Patch
Comment on attachment 407875 [details] Patch r+ing this so it can land in WebKit. The ANGLE team are currently looking at it upstream.
Committed r266539: <https://trac.webkit.org/changeset/266539> All reviewed patches have been landed. Closing bug and clearing flags on attachment 407875 [details].
*** Bug 217381 has been marked as a duplicate of this bug. ***