Webrender completely broken on Mac (10.14, Intel HD Graphics 4000)
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox-esr68 | --- | unaffected |
firefox68 | --- | unaffected |
firefox69 | --- | unaffected |
firefox70 | --- | verified |
firefox71 | --- | fixed |
firefox72 | --- | fixed |
firefox76 | --- | wontfix |
firefox77 | --- | wontfix |
firefox78 | --- | wontfix |
firefox79 | --- | fixed |
People
(Reporter: robin, Assigned: kvark)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(10 files)
87.91 KB,
image/png
|
Details | |
138.91 KB,
image/png
|
Details | |
47 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
Details | Review |
20.21 KB,
image/png
|
Details | |
329.89 KB,
image/png
|
Details | |
47 bytes,
text/x-phabricator-request
|
pascalc
:
approval-mozilla-beta+
|
Details | Review |
26.19 KB,
application/json
|
Details | |
466.62 KB,
image/png
|
Details | |
47 bytes,
text/x-phabricator-request
|
Details | Review | |
354.11 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:70.0) Gecko/20100101 Firefox/70.0
Steps to reproduce:
Installed latest Nightly 2 days ago, restarted Firefox. This on a Macbook Air 11" 2012 on latest 10.14.6. So that means Intel i5 with HD Graphics 4000, with Webrender manually enabled.
Actual results:
Complete font and image breakage. Rendering boxes and general layout components seems to still work. See screenshots.
Expected results:
Normal display. If I turn webrender off (manual editing of prefs.js is easiest) then we’re back to normal; I’m filing this bug from that setup.
Reporter | ||
Comment 1•6 years ago
|
||
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Comment 2•6 years ago
|
||
Attempted to reproduce, but was unable to get the issue to manifest with devices having Intel IRIS pro 1536, Intel IRIS plus 650.
Your issue might be limited to the graphics setup.
@Robin, any chance you could install mozregression and run a check for the regression range?
Comment 3•6 years ago
|
||
Oof, the corruption you're seeing is a classic example of us messing up the texture cache (basically everything that we cache a rasterization of like images/glyphs gets replaced with random textures). Sadly something that can happen in various different ways. Haven't seen this on any of our macs yet, though. Maybe the supplemental macos update that just came out is involved (https://support.apple.com/kb/DL2015?locale=en_US)? Do you have that one installed yet? (sadly I don't think it shows up as a difference in macos version number)
A regression range would definitely be helpful.
Reporter | ||
Comment 4•6 years ago
|
||
Nope, this is post 10.14.6, pre supplemental update. I’ll run mozregression though and get back to you with a range.
Reporter | ||
Comment 5•6 years ago
|
||
Mozregression came up with https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ce76fa05c90f3f24f8db09950eadd4a8cdec9088&tochange=bc58681d24079ae0bdb65c9679455042dccf0e76 , which looks suitably suspicious :)
Updated•6 years ago
|
Comment 6•6 years ago
|
||
Awesome, thanks!
I also managed to reproduce this locally! Found an old 2012 macbook air in the office and updated it (was running macos 10.10 and firefox 56 🙀).
Assignee | ||
Updated•6 years ago
|
Assignee | ||
Comment 7•6 years ago
|
||
The texture cache is fine. Problem only manifests itself when sampling from it with swizzling states set up. It looks like setting those GL_TEXTURE_SWIZZLE states corrupts the other sampling parameters, likely a driver bug. Only seen on Intel 4000 so far - the same machine running on NVidia is fine (i.e. even replaying the same WR capture).
I've added it to https://github.com/servo/webrender/wiki/Driver-issues
Currently trying to narrow down the bug in https://github.com/kvark/gl-swizzle-test
As a short term solution we could also flip "allow_texture_swizzling = false" in RendererOptions
when we detect Intel 4000 series GPU on MacOS.
Assignee | ||
Comment 8•6 years ago
|
||
Managed to reproduce it, at last, in the artificial test app. Basically, setting up the swizzle state on a texture unit breaks the result of textureSize
instruction of GLSL, which WebRender relies on. I believe the best course of action is to blacklist swizzling for IvyBridge GPU family on Mac.
Assignee | ||
Comment 9•6 years ago
|
||
Investigation showed that on this platform the texture unit state becomes
corrupted whenever we set the non-identity swizzling (getting garbage from textureSize()).
Given no easy workaround, we disable swizzling for this GPU family on Mac, for now.
Comment 10•6 years ago
|
||
Comment 11•6 years ago
|
||
bugherder |
Reporter | ||
Comment 12•6 years ago
|
||
This patch fixes the original problem, but seems to have introduced interesting colour shifts. This appears to be a ROT13 style problem (can you tell I’m not a graphics person?) as the screenshots of the broken behaviour appear fine in the preview display of the bug upload field.
Reporter | ||
Comment 13•6 years ago
|
||
Assignee | ||
Comment 14•6 years ago
|
||
Robin: yes, this is known and filed separately as Bug 1572843. The fix is going through the review now.
Reporter | ||
Comment 15•6 years ago
|
||
OK, cool, I’ll VERIFY this one as fixed then.
Comment 16•5 years ago
|
||
Thank you, Robin!
Comment 17•5 years ago
|
||
Macbook Air 13 Mid 2011, macbookair 4,2, Intel HD 3000 384 MB.
MacOs High Sierra 10.13.6 (17G8037)
The bug is still there. Just upgraded to firefox 70.
Assignee | ||
Comment 18•5 years ago
|
||
We blocklisted Intel 4000, while your device is HD 3000... Let's follow-up with blocklisting the swizzling code for this as well.
Assignee | ||
Comment 19•5 years ago
|
||
Comment 20•5 years ago
|
||
Comment 21•5 years ago
|
||
bugherder |
Comment 22•5 years ago
|
||
Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.
Comment 23•5 years ago
|
||
Please nominate this for Beta uplift when you get a chance.
Assignee | ||
Comment 24•5 years ago
|
||
Comment on attachment 9104646 [details]
Blocklist WR swizzling on HD3000
Beta/Release Uplift Approval Request
- User impact if declined: Intel HD3000 users on macOS would get broken WebRender (although they still have to opt into that)
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): It's just expanding the blocklist, not risky.
- String changes made/needed:
Assignee | ||
Updated•5 years ago
|
Comment 25•5 years ago
|
||
Hello,
I verified and in nightly the bug has gone. So apparently the fix is working.
Comment 26•5 years ago
|
||
Comment on attachment 9104646 [details]
Blocklist WR swizzling on HD3000
Low risk, Webrender fix for a subset of our mac user-base by blocklisting a board model, approved for 71 beta 6, thanks.
Updated•5 years ago
|
Comment 27•5 years ago
|
||
bugherder uplift |
Comment 28•5 years ago
|
||
I'm currently seeing a similar issue on Firefox 71.0 with HD 5000. I initially believed it was due to bug 1586627, but after more thorough searching this bug and bug 1562462 point to the webrender issue as being more likely.
Firefox 71.0
Mojave/10.14.6
MacBook Pro (Retina, 13-inch, Late 2013) (MacBookPro11,1)
Intel Core i5 / 2.6 GHz
Memory: 16 GB
Intel HD Graphics 5100
VRAM (Dynamic, Max): 1536 MB
Assignee | ||
Comment 29•5 years ago
|
||
ckoff, could you please attach the "about:support" output?
Comment 30•5 years ago
|
||
Assignee | ||
Comment 31•5 years ago
|
||
ckoff, thank you! So this is Haswell iGPU, it's not in the block list for this feature.
Could you provide more information about what you are experiencing? we need to double-check if this is indeed the same issue. It would be highly unfortunate if we had to block-list Haswell swizzling. Please attach a screen shot and ideally a WR capture. You can get it by hitting "CTRL + SHIFT + 3" when you see the problem, it is saved in the "~/wr-capture" folder (which you'd need to pack into a file and maybe send my way via Firefox Send or any other service). Thank you in advance!
Comment 32•5 years ago
|
||
Can confirm that enabling webrender in FF 74.0 on a 2012 mac mini with Intel HD Graphics 4000 produces this problem.
Conversation at #gfx: https://matrix.to/#/!wbEUPKmXGxodKqLlZL:mozilla.org/$HO8SQXRwbC5hTy25_FAouBtftVRjfIDWGWl1_vKFgv8?via=mozilla.org&via=matrix.org&via=amorgan.xyz
Updated•5 years ago
|
Comment 33•5 years ago
|
||
Starting to look at blocking Mac bugs. Dzmitry, do you have any theories as to was was happening here with swizzling?
Assignee | ||
Comment 34•5 years ago
|
||
It's hard to investigate without affected platform/hardware by hand... Something in the swizzling logic got broke. It could be that the issue Alan sees is different from previously reported one, since HD Graphics 4000 is blacklisted for swizzling.
Alan, it would help to get the output from WebRender logging:
cd webrender/examples
RUST_LOG=webrender=info cargo run --bin basic
Could you provide it from the affected machine?
Comment 35•5 years ago
|
||
Here's a screenshot (running via RDP, so this is the best I could do).
Comment 36•5 years ago
|
||
Also, to get this bug I had to force webrender to be enabled. (I am originally seeing this on Servo, which doesn't use the blocklisting).
Assignee | ||
Comment 37•5 years ago
|
||
Thank you!
That's the same as I'm getting on my Linux machine, and this path should be fairly solid. I wonder if we are seeing the same issue we blocklisted before.
Could you run https://github.com/kvark/gl-swizzle-test on that machine and report what you see, please?
Assignee | ||
Comment 38•5 years ago
|
||
Notably, the only thing that changed the relevant swizzle paths is https://phabricator.services.mozilla.com/D65596, so bug 1612941 is a candidate to be causing this regression. cc Lee
Assignee | ||
Comment 39•5 years ago
|
||
Here is what I found:
- https://phabricator.services.mozilla.com/D65596 does change the logic in a way that it requires
ARB_texture_swizzle
on GL. Previously, it was assumed to be available on desktop GL. - macOS doesn't appear to report "ARB_texture_swizzle" at all, at least there are no reports. The relevant article implies that macOS with OpenGL 3.2 should report the extension though. Would be good to double check that.
- the combination of these factors mean that bug 1612941 broke swizzle detection on macOS. I'm fixing this.
Assignee | ||
Comment 40•5 years ago
|
||
Assignee | ||
Comment 42•5 years ago
|
||
Thank you!
It seems to me that your hardware should fall under the blacklist already. Providing about:support would make it more evident.
Unless... the code path that doesn't swizzle is currently broken. I need to look into this more.
I guess I can try blocking the swizzling on my mac and checking how it works, that would be a good test.
Comment 43•5 years ago
|
||
It is, like I said you have to force-enable webrender to get this behaviour, this is more of a Servo issue in that we don't have a blocklist/allowlist for individual gfx cards.
Comment 44•5 years ago
|
||
Comment 45•5 years ago
|
||
bugherder |
Assignee | ||
Comment 46•5 years ago
|
||
I also made a try push that force-disables the use of GL swizzling, to simulate the conditions we have on the machines where it's supported but black-listed. It works fine on my macbook Intel with Broadwell GPU. Let's see if there are any reports after https://phabricator.services.mozilla.com/D77896 is landed.
Updated•5 years ago
|
Updated•5 years ago
|
Reporter | ||
Comment 49•5 years ago
|
||
Not from me, I never saw it again after I verified fixed in https://bugzilla.mozilla.org/show_bug.cgi?id=1570736#c15
Comment 50•4 years ago
|
||
(ckoff and ajeffrey are gone)
Description
•