1443181 - Facebook game 8 Ball Pool smeared v>=60 for GMA 4500

Status: REOPENED

(Core :: Graphics: CanvasWebGL, defect, P2)

Description

[Ton [:Tonnes]]

Attachment: Image of issue

Facebook 8-Ball Pool started to show smeared parts on Win 7 in nightly builds as of March 3. Perhaps related to bug 1442608 or 1421818?

Last good build: BuildID=20180302220122
First bad build: BuildID=20180303100406

Comment 1

[Darkspirit]

> You need to install Adobe Flash Player to play 8 Ball Pool. Download the Flash Player now.

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Can you still reproduce the issue?

Comment 3

[Ton [:Tonnes]]

Yes, even in today’s build. Do you need any console or other info?

Comment 4

[Jeff Muizelaar [:jrmuizel]]

I can't reproduce on mac or Windows. Since, you have a regression range can you narrow it down using mozregression?

Comment 5

[Ton [:Tonnes]]

Last good build: 9f87ddff4b02b89cc5530b4cb8ec767b14f4c687
First bad build: 2c120740c252c63b781cb99ebf02cfa46c23ff32
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9f87ddff4b02b89cc5530b4cb8ec767b14f4c687&tochange=2c120740c252c63b781cb99ebf02cfa46c23ff32

Comment 6

[Jeff Muizelaar [:jrmuizel]]

So the ANGLE update in bug 1440849 seems the most suspicious. Can you reproduce this without webrender on?

Comment 7

[Ton [:Tonnes]]

How? Fwiw, all prefs containing webrender are set as default, hence gfx.webrender.enabled is false, gfx.webrender.force-angle is true. Same in any new profile, flipping either of them makes no difference. Hw acceleration is partly disabled though, i.e. the onboard chipset is blocked for D2D, its pref is always enabled by default in Options nevertheless and I need to disable it manually for any profile to prevent certain issues. Doing so here makes no difference for this issue (it just turned up with hw accel already disabled).

Comment 8

[Jeff Muizelaar [:jrmuizel]]

I'm not sure how wide spread this problem is but we should try to find out.

Comment 9

[Kelsey Gilbert [:jgilbert]]

So is this WebGL or not?

If WebGL, I'll help hunt this down, but otherwise this should be investigated from the WebRender side.

Comment 10

[Jeff Muizelaar [:jrmuizel]]

This is WebGL. It reproduces with WebRender off see: https://bugzilla.mozilla.org/show_bug.cgi?id=1443181#c7

Comment 11

[Ton [:Tonnes]]

(In reply to Jeff Gilbert [:jgilbert] from comment #9)
> So is this WebGL or not?

I’m not sure, you probably know better. Is there anything I could test or do more to help out?

Comment 12

[Ton [:Tonnes]]

Attachment: TS info - Graphics section

Copy of today’s nightly en-US Graphics section in TS info, as requested by philipp.

Comment 13

[Julien Cristau [:jcristau]]

This doesn't feel like it would be dot-release material, so setting status to wontfix for firefox 60.

Comment 14

[David Bolter [:davidb] (NeedInfo me for attention)]

Seems like this is Jeff Gilbert's area. Jeff please reassign if I'm wrong. Do you think this was the Angle update?

Comment 15

[Ton [:Tonnes]]

Used mozregression once again and I may have actually submitted the wrong pushlog_url (sorry). Bisecting pointed to this one:

Last good build: d9f8ec82354d03faa5e0475004ffb8cc31bad8d6
First bad build: 58b3bc37c7f8a18abb2cf2c669fe5547b87ed0a6
Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d9f8ec82354d03faa5e0475004ffb8cc31bad8d6&tochange=58b3bc37c7f8a18abb2cf2c669fe5547b87ed0a6

End of log view:
2018-05-18T20:02:26: INFO : Narrowed inbound regression window from [d9f8ec82, 58b3bc37] (3 builds) to [d9f8ec82, 8ee92682] (2 builds) (~1 steps left)
2018-05-18T20:02:26: DEBUG : Starting merge handling...
2018-05-18T20:02:26: DEBUG : Using url: https://hg.mozilla.org/integration/mozilla-inbound/json-pushes?changeset=8ee92682ad1f3b67c110742bc910cf1af03ac48b&full=1
2018-05-18T20:02:27: DEBUG : Found commit message:
Bug 1440849 - Update ANGLE to firefox-60 branch.

Comment 16

[Kelsey Gilbert [:jgilbert]]

I cannot reproduce this issue. Are there any more details? The initial break scene rendered fine for me.

I see the driver date for you is from 2012. Can you update your graphics driver? We may need to push you off the GPU onto WARP to ensure things render properly.

Comment 17

[Ton [:Tonnes]]

First, I cannot reproduce the issue myself at this point in (latest) 60 and 61 nightlies, nor current Nightly 62. FB recently upgraded the 8 Ball Pool webapp from v 1.x.x to v 2.0, which is probably the reason. For reproducing in general, I would advise to try on a machine with the same Intel chipset (G41/G43/G45).

Basically there is no newer graphics driver available than the one in use / reported, although a newer one with the following changes shows up @ Intel when attempting to download v 8.15.10.2869 (=8.15.10.2993):
- Fixed artifacts seen when rendering triangle strips in an OpenGL * MATLAB* sample.
- Fixed issue where an OpenGL sample application extends off-screen when the application is changed to full-screen.
- Fixed issue where some laptop screens may be blank after updating the graphics driver and rebooting.

I’m not sure whether or not the above would fix issues resulting from any changes affecting Firefox around the given regression range, either related to Angle or not. Updating the driver however requires some efforts (system is permanently in use) and be to no avail without possible reproduction. And as odd as it may seems, I have not tested in 60 release with the older webapp as I don’t use that version as default browser yet.

Too many parameters. The fear of course is the issue may show up for other webapps and for various chipsets/drivers (from mainboard manufacturers rather than Intel), something that may have become clear when verifying/triaging a bit earlier around the time of reporting.

For now, it may be safe to mark this WFM - it can be reopened when the issue returns or comparable ones turn up.

Comment 18

[Kelsey Gilbert [:jgilbert]]

Thanks for the details. We'll mark this WFM for now.

Comment 19

[Ton [:Tonnes]]

I’m afraid someone ran into the same issue on 60 esr with another game. Can you please have a look at https://support.mozilla.org/questions/1218843?

Comment 20

[Ton [:Tonnes]]

Reopening as the issue was kind of confirmed - forcing to WARP by the user seems to be a workaround - see the support question.

(As written there, trying other methods as a fix beforehand rather than forcing to use WARP if possible would be appreciated.)

Comment 21

[BugBot [:suhaib / :marco/ :calixte]]

Moving to p3 because no activity for at least 24 weeks.
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 22

[Kelsey Gilbert [:jgilbert]]

Alright, so I think I know what this is.

We're not even supposed to be running d3d11 on this hardware: ("Intel(R) G41 Express Chipset" appears to be GMA X4500)
https://searchfox.org/mozilla-central/source/widget/windows/GfxInfo.cpp#1517

There's a ton of spaghetti code to get to here:
FEATURE_DIRECT3D_11_ANGLE
=> Feature::D3D11_HW_ANGLE
=> https://dxr.mozilla.org/mozilla-esr60/source/gfx/gl/GLLibraryEGL.cpp#292 :

  if (gfxConfig::IsForcedOnByUser(Feature::D3D11_HW_ANGLE)) {
    return GetAndInitDisplay(egl, LOCAL_EGL_D3D11_ONLY_DISPLAY_ANGLE);
  }

  if (d3d11ANGLE.IsEnabled()) {
    ret = GetAndInitDisplay(egl, LOCAL_EGL_D3D11_ELSE_D3D9_DISPLAY_ANGLE);
  }

  if (!ret) {
    ret = GetAndInitDisplay(egl, EGL_DEFAULT_DISPLAY);
  }

So normal users aren't force-enabled, but they shouldn't be d3d11ANGLE.IsEnabled() either, so we should take the EGL_DEFAULT_DISPLAY path.

Tracing that into ANGLE:
https://searchfox.org/mozilla-central/rev/da3f3eaaacb6fb344fd21ac29ace2da0e33f12d3/gfx/angle/checkout/src/libANGLE/renderer/d3d/DisplayD3D.cpp#86

            // The default display is requested, try the D3D9 and D3D11 renderers, order them using
            // the definition of ANGLE_DEFAULT_D3D11
#if ANGLE_DEFAULT_D3D11
#    if defined(ANGLE_ENABLE_D3D11)
            rendererCreationFunctions.push_back(CreateTypedRendererD3D<Renderer11>);
#    endif
#    if defined(ANGLE_ENABLE_D3D9)
            rendererCreationFunctions.push_back(CreateTypedRendererD3D<Renderer9>);
#    endif
#else
#    if defined(ANGLE_ENABLE_D3D9)
            rendererCreationFunctions.push_back(CreateTypedRendererD3D<Renderer9>);
#    endif
#    if defined(ANGLE_ENABLE_D3D11)
            rendererCreationFunctions.push_back(CreateTypedRendererD3D<Renderer11>);
#    endif
#endif

Oh, let's check on ANGLE_DEFAULT_D3D11:
ESR52 (working): https://dxr.mozilla.org/mozilla-esr52/search?q=ANGLE_DEFAULT_D3D11
ESR60 (broken): https://dxr.mozilla.org/mozilla-esr60/search?q=ANGLE_DEFAULT_D3D11
Oops.

The GLLibraryEGL code is treating EGL_DEFAULT_DISPLAY as d3d9, which stopped being the case when we lost this moz.build define in the angle update/refactor in 60.

We should really ask for d3d9 explicitly when we want d3d9.

Comment 23

[Kelsey Gilbert [:jgilbert]]

Attachment: Bug 1443181 - If ANGLE D3D11 disabled, ask for D3D9 explicitly.

Comment 24

[Kelsey Gilbert [:jgilbert]]

I don't like relying on the magic DEFINES['ANGLE_DEFAULT_D3D11'] = "0" line to keep working, particularly since this was the second time we've accidentally deleted it during an ANGLE update.

So let's ask for d3d9 explicitly instead.

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a6f3fd30a0a7
If ANGLE D3D11 disabled, ask for D3D9 explicitly. r=lsalzman

Comment 26

[Raul Gurzau (:RaulG)]

https://hg.mozilla.org/mozilla-central/rev/a6f3fd30a0a7

Comment 27

[Kelsey Gilbert [:jgilbert]]

[Tracking Requested - why for this release]:
Users on "Intel(R) G41 Express Chipset" (GMA X4500, which is a lot of people) have reported bad rendering on some games, and now we can help them.

Comment 28

[Ryan VanderMeulen [:RyanVM]]

Given that it's a longstanding issue, I don't think we need to start tracking it now just because we have a patch. That said, I'm happy to entertain an approval request if you think we should consider uplifting to Fx69/ESR68 :-).

Comment 29

[Kelsey Gilbert [:jgilbert]]

I'll be asking for uplifts after verification!

Comment 30

[Daniel Bodea [:danibodea]]

I could not reproduce the issue on the original affected build, Nightly v60.0a1 from 2018-03-03.
Also, I do not have the "Intel(R) G41 Express Chipset" that is also a cause of this issue.
Moreover, the reporter states that he could not reproduce the issue either, in firefox60, firefox61 and firefox62 even before the fix, but the test page (facebook game 8 pool) got an update, therefore the test page may be invalid now.

This being said, this bug's fix cannot be verified unless another method to reproduce is found.

Jeff, do you know any other test page to reproduce this issue?

Comment 31

[Kelsey Gilbert [:jgilbert]]

I don't. I would like to take this blacklisting fix in esr68 though, since that'll be with us for some time.

Comment 32

[Kelsey Gilbert [:jgilbert]]

Comment on attachment 9076704 [details]
Bug 1443181 - If ANGLE D3D11 disabled, ask for D3D9 explicitly.

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Fixes a regression from v60, where users of a fairly common GPU were supposed to have d3d11 blocklisted due to unreliable d3d11 on that device, but became accidentally unblocked in v60.
• User impact if declined: Users on a fairly common GPU may run into WebGL content (e.g. Facebook games) that behaves badly, including at the very least bad rendering.
• Fix Landed on Version: 70
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Low risk, fixes a regression, but we don't have a device to test this on.
• String or UUID changes made by this patch: none

Comment 33

[Kelsey Gilbert [:jgilbert]]

Comment on attachment 9076704 [details]
Bug 1443181 - If ANGLE D3D11 disabled, ask for D3D9 explicitly.

Beta/Release Uplift Approval Request

• User impact if declined: Users on a fairly common GPU may run into WebGL content (e.g. Facebook games) that behaves badly, including at the very least bad rendering.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: esr68
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Low risk, fixes a regression, but we don't have a device to test this on.
• String changes made/needed: none

Comment 34

[Daniel Bodea [:danibodea]]

I have attempted to reproduce it again on 2 other more lo-end systems but with still no success.
We don't have the chipset that the reporter has AND the game the issue was logged for appears to have been updated.

This given, we cannot correctly verify the fix of this issue.
Removing the "qe-verify+" tag.

Comment 35

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9076704 [details]
Bug 1443181 - If ANGLE D3D11 disabled, ask for D3D9 explicitly.

Seems like a low-risk fix, but the inability to verify is a bit concerning. Let's take this for 69.0b5 and let it bake for a bit.

Comment 36

[Razvan Maries]

https://hg.mozilla.org/releases/mozilla-beta/rev/3259bd848059

Comment 37

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9076704 [details]
Bug 1443181 - If ANGLE D3D11 disabled, ask for D3D9 explicitly.

I'm not convinced there's enough need for this fix on ESR to justify uplift, and regressions may not be immediately obvious given the lack of test coverage. Let's let this ride the regular trains.

Comment 38

[Ryan VanderMeulen [:RyanVM]]

This was backed out from 69 & 70 for causing bug 1571838.

https://hg.mozilla.org/integration/autoland/rev/975f26e0fff1
https://hg.mozilla.org/releases/mozilla-beta/rev/f804b4a4668f

Comment 39

[BugBot [:suhaib / :marco/ :calixte]]

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:jgilbert, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 44

[Julien Cristau [:jcristau]]

Restricting comments on this old bug that has begun attracting spam.