1216366 - Black boxes since 2014-07-10 with e10s off and D3D11 OMTC HWA, D2D off

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Oriol Brufau [:Oriol]]

Attachment: testcase (by :mstange)

Same problem as bug 1211615, but now with D3D11 instead of D3D9.

Open this testcase (by :mstange): https://bugzilla.mozilla.org/attachment.cgi?id=8672525

Some black boxes appear

Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d0b48a557161308bc7459afe0f7ce5fbcd8e51c5&tochange=ee863cf58138c1d0c5eecd19334ecf68fa1f5ad2

Comment 1

[Ryan VanderMeulen [:RyanVM]]

I got a bit confused by the various bugs we had on file for these issues. Does this still reproduce for you since bug 1211615 landed? If so, can you please narrow the regression range down with mozregression? I haven't been able to reproduce using the attached testcase personally.

Comment 2

[Oriol Brufau [:Oriol]]

Yes, I can reproduce this on Win7 64-bit, nightly 2015-11-16.
I already used mozregression to get the regression range in comment 0.

Comment 3

[Ryan VanderMeulen [:RyanVM]]

Thanks for confirming that this still reproduces. Disappointing, but good to know :)

The regression window from comment 0 is really confusing, though. It appears to be pointing at a b2g-inbound or fx-team change as the culprit, but nothing really stands out from those pushes that would appear to be a likely candidate. Can you please double-check that range to make sure it reliably comes back to that?

More specifically, if I widen the pushlog range you provided, I see a maybe-interesting push from Bas a bit further down: https://hg.mozilla.org/integration/mozilla-inbound/rev/51798e7d8abc (bug 1161815)

There's also https://hg.mozilla.org/integration/mozilla-inbound/rev/8985391fa24c (bug 1162179), but that seems unlikely since I'm pretty sure APZC wasn't enabled on Windows then.

If it helps, I can probably spin before/after builds from that range if we want to test either of those more specifically, though.

Comment 4

[Oriol Brufau [:Oriol]]

The regression range in comment 0 might be wrong. Moz-regression says the change is between 2015-05-06 and 2015-05-07 nightlies. Then it offers inbound builds but they are all OK. So I suspect it checks in the wrong inbound range.

But it doesn't matter. I have noticed that since gfx.blacklist.direct2d is not 4 by default, before 2015-05-07 there is no problem during the first run of a new profile. But it's switched automatically to 4, and that produces the issue on following runs, even before 2015-05-07.

Then, the regression range with gfx.blacklist.direct2d=4 is
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=196d05832e12&tochange=cb75d6cfb004

It seems there aren't inbound builds of that dates.

Comment 5

[Oriol Brufau [:Oriol]]

Adding 1217215 as related since both have same regression range.

It seems in my case I got the issue because Firefox detects unresolved driver issues with D2D, so it is automatically disabled through gfx.blacklist.direct2d=4.

I have another computer with Win10 where I couldn't reproduce the issue, but now I can with gfx.direct2d.disabled=true.

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Hey cool, I can reproduce too with Direct2D disabled :)

I'll try to bisect this locally.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Local bisection confirms that this is a regression from bug 1035227.

Comment 8

[Bas Schouten (:bas.schouten)]

Attachment: Ensure D3D11 uploads the entire surface the first time for component alpha textures.

It's a little silly of me not to test this on D3D11 when I fixed the other two cases. I thought it would be included in BufferTextureHost. My apologies.

Comment 9

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ce1ab07ca576

Comment 10

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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

Comment 11

[Oriol Brufau [:Oriol]]

Can it be uplifted, like bug 1211615?