Open Bug 1443181 Opened 2 years ago Updated 9 days ago

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

Categories

(Core :: Canvas: WebGL, defect, P1)

Unspecified
Windows 7
defect

Tracking

()

REOPENED
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 - wontfix
firefox-esr68 - wontfix
firefox59 --- unaffected
firefox60 - wontfix
firefox61 + unaffected
firefox62 + unaffected
firefox68 --- wontfix
firefox69 - wontfix
firefox70 --- wontfix
firefox72 --- wontfix
firefox73 --- wontfix
firefox74 --- wontfix

People

(Reporter: Tonnes, Assigned: jgilbert)

References

(Regression, )

Details

(Keywords: nightly-community, regression, Whiteboard: [gfx-noted] [sci-exclude])

Attachments

(3 files)

Attached image 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
OS: Unspecified → Windows 7
Can you still reproduce the issue?
Flags: needinfo?(tonnes.mb)
Yes, even in today’s build. Do you need any console or other info?
Flags: needinfo?(tonnes.mb)
I can't reproduce on mac or Windows. Since, you have a regression range can you narrow it down using mozregression?
Flags: needinfo?(tonnes.mb)
Last good build: 9f87ddff4b02b89cc5530b4cb8ec767b14f4c687
First bad build: 2c120740c252c63b781cb99ebf02cfa46c23ff32
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9f87ddff4b02b89cc5530b4cb8ec767b14f4c687&tochange=2c120740c252c63b781cb99ebf02cfa46c23ff32
Flags: needinfo?(tonnes.mb)
So the ANGLE update in bug 1440849 seems the most suspicious. Can you reproduce this without webrender on?
Flags: needinfo?(tonnes.mb)
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).
Flags: needinfo?(tonnes.mb)
Component: Graphics: WebRender → Canvas: WebGL
Blocks: angle-60
No longer blocks: stage-wr-nightly
Flags: needinfo?(jgilbert)
I'm not sure how wide spread this problem is but we should try to find out.
So is this WebGL or not?

If WebGL, I'll help hunt this down, but otherwise this should be investigated from the WebRender side.
Flags: needinfo?(jgilbert) → needinfo?(tonnes.mb)
This is WebGL. It reproduces with WebRender off see: https://bugzilla.mozilla.org/show_bug.cgi?id=1443181#c7
Flags: needinfo?(jgilbert)
(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?
Flags: needinfo?(tonnes.mb)
Whiteboard: [gfx-noted]
Copy of today’s nightly en-US Graphics section in TS info, as requested by philipp.
This doesn't feel like it would be dot-release material, so setting status to wontfix for firefox 60.
Seems like this is Jeff Gilbert's area. Jeff please reassign if I'm wrong. Do you think this was the Angle update?
Assignee: nobody → jgilbert
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.
Flags: needinfo?(jgilbert)
Flags: needinfo?(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.
Flags: needinfo?(jgilbert) → needinfo?(tonnes.mb)
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.
Flags: needinfo?(tonnes.mb)
Thanks for the details. We'll mark this WFM for now.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
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?
Flags: needinfo?(jgilbert)
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.)
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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
Priority: P1 → P3

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.

Flags: needinfo?(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.

Priority: P3 → P1
Summary: Facebook game 8 Ball Pool smeared in current Nightly → Facebook game 8 Ball Pool smeared v>=60 for GMA 4500
Pushed by jgilbert@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a6f3fd30a0a7
If ANGLE D3D11 disabled, ask for D3D9 explicitly. r=lsalzman
Status: REOPENED → RESOLVED
Closed: 2 years ago1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla70

[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.

Flags: qe-verify+

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 :-).

I'll be asking for uplifts after verification!

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?

Flags: needinfo?(jgilbert)

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

Flags: needinfo?(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
Attachment #9076704 - Flags: approval-mozilla-esr68?
No longer blocks: angle-60
Regressed by: angle-60

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
Attachment #9076704 - Flags: approval-mozilla-beta?
QA Whiteboard: [qa-triaged]

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.

QA Whiteboard: [qa-triaged]
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

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.

Attachment #9076704 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Regressions: 1571838

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.

Attachment #9076704 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68-
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla70 → ---
QA Whiteboard: [qa-triaged] → [qa-triaged] [sci-exclude]
QA Whiteboard: [qa-triaged] [sci-exclude] → [qa-triaged]
Whiteboard: [gfx-noted] → [gfx-noted] [sci-exclude]

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.

Flags: needinfo?(jgilbert)
Flags: needinfo?(jgilbert)
You need to log in before you can comment on or make changes to this bug.