Screen artifacts on Intel HD 520 with webrender.compositor
Categories
(Core :: Graphics: WebRender, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr68 | --- | unaffected |
firefox71 | --- | unaffected |
firefox72 | --- | unaffected |
firefox73 | --- | fixed |
People
(Reporter: yoasif, Assigned: sotaro)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: nightly-community, regression)
Attachments
(5 files)
I'm getting random artifacts on my screen with the 12/9 build. It goes away if I disable webrender. I'm running Windows 10 x64 with an Intel HD 520 chipset.
Regressed by: Bug 1592509 - Enable gfx.webrender.compositor by default on Windows r=gw
Reporter | ||
Comment 1•5 years ago
|
||
Reporter | ||
Updated•5 years ago
|
I'm the OP on the Reddit thread for this. I've seen these artifacts on about:newtab, gmail.com as well as Reddit so far. It seems to happen when moving the mouse around random parts of the screen, and in the case of the screenshot, the artifacts blink when the input field is selected on Reddit. I will attempt to grab video of this and post it to this thread.
Reporter | ||
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 4•5 years ago
|
||
I think this might be a driver bug (I've seen something similar on an HD530 running an older driver).
The Intel driver in about:support is:
Description: Intel(R) HD Graphics 520
Driver Version: 24.20.100.6293
Driver Date: 9-26-2018
The most recent driver 26.20.100.7463
(https://downloadcenter.intel.com/product/88355/Intel-HD-Graphics-520).
Is it possible (depending on how your machine / environment is set up) to try updating to the most recent Intel driver?
Ideally we would find a workaround for this, even if it is a driver bug - but it'd be good to confirm whether that is the case.
(In reply to Glenn Watson [:gw] from comment #4)
I think this might be a driver bug (I've seen something similar on an HD530 running an older driver).
The Intel driver in about:support is:
Description: Intel(R) HD Graphics 520 Driver Version: 24.20.100.6293 Driver Date: 9-26-2018
The most recent driver
26.20.100.7463
(https://downloadcenter.intel.com/product/88355/Intel-HD-Graphics-520).Is it possible (depending on how your machine / environment is set up) to try updating to the most recent Intel driver?
Ideally we would find a workaround for this, even if it is a driver bug - but it'd be good to confirm whether that is the case.
The only concern I have about updating my driver, is that this is on a Surface Book. Microsoft is pretty picky about the drivers that the device runs.
Attempted to install the drivers listed on the Intel website, and the driver is not validated for the hardware that I'm running (Microsoft Surface Book).
Comment 7•5 years ago
|
||
Yes, fair enough! I'll see if we can find another way to repro it. In the meantime, you can disable gfx.webrender.compositor
in about:config
as a temporary workaround (or we might disable it by default if we see a significant number of users seeing the same issue).
Will do. Thank you! Let me know if you need any further info, or to perform any other tests.
Comment 10•5 years ago
|
||
(Accidentally posted this in the dup bug)
I can reproduce this now.
I have an HD530 machine that is working correctly. I downloaded the old 6293 driver that is installed in both of the bug reports above. Windows doesn't want to install the driver on the HD530. If I force install it, it thinks it is an HD520, but it does now seem to reproduce the issue.
The artifacts are not appearing along where the tile boundaries are, but they do seem to line up with the update rectangles (if you're able to enable gfx.webrender.debug.picture-caching and provide a screenshot with the artifact occurring, I can confirm that what I'm seeing matches the artifact you're seeing).
I'll do some logging and debugging around our update rects.
I suspect it to be a driver bug since it only appears on this driver version / hardware, but it's possible that our update rect(s) are either slightly incorrect due to rounding, or something similar.
If it is a driver bug, it's possible that we could still keep DC enabled on this driver version, but disable partial update rects, though that would be unfortunate.
Comment 11•5 years ago
|
||
From what I can tell so far, this is a driver bug.
I've confirmed that the update rectangles look correct. I've also tried to set the interpolation mode on the root visual to nearest, but that had no effect.
If I set gfx.webrender.compositor.max_update_rects
to 0, most of the artifacts go away. It'd be interesting to find out if that's the same on your machines. Despite that, I still see the artifact occasionally while scrolling, just not anywhere near as frequently.
I'll keep investigating, but I think we might need to blacklist that driver version from enabling the OS compositor mode, if we have support for that in Gecko?
Comment 12•5 years ago
|
||
I've confirmed:
- I can reproduce the bug locally by installing the
6293
driver, both in Gecko and in the simple example-compositor application. - The offsets, clip rects and update rects have correct values and are rounded correctly to int values.
- Changing the DC interpolation mode to linear / nearest has no effect on the artifact.
- Updating to the most recent driver on the Intel web site (forcing install even though it's not validated) fixes the problem in both Gecko and the example-compositor application.
- There are some vague references in recent Intel driver release notes to fixing artifacts in MS Edge, Win10 Start Menu and Win10 Store - all of these applications use DirectComposition, so these notes may refer to the same bug we're seeing here.
Given that, I think we should add support to Gecko for blacklisting DirectComposition mode, based on this specific driver version. Users on this driver version will fall back to normal picture caching webrender mode, which will not get the performance / battery wins of DC, but should avoid this artifact. If / when MS pushes out a driver update for the Surface to the most recent Intel driver, then Gecko will automatically opt back in to DC mode.
Sotaro, is it reasonably easy to add support for blacklisting DC on this driver?
Assignee | ||
Comment 13•5 years ago
•
|
||
(In reply to Glenn Watson [:gw] from comment #12)
I've confirmed:
Sotaro, is it reasonably easy to add support for blacklisting DC on this driver?
It seems not complex to block DC for the driver. I could work for it. And it is nice, it we could see the DC blocking in about:support.
Assignee | ||
Comment 14•5 years ago
|
||
I am going to work for creating a patch.
Assignee | ||
Comment 15•5 years ago
|
||
Assignee | ||
Comment 16•5 years ago
|
||
Comment on attachment 9114848 [details]
Bug 1602511 - Blacklist webrender compositor on Intel HD 520
:gw, can you feedback to the patch?
Comment 17•5 years ago
|
||
Can't make comments in fabricator, thus posting here: should it be DRIVER_LESS_THAN
the known good version instead DRIVER_EQUAL
one version that is known bad?
Assignee | ||
Comment 18•5 years ago
•
|
||
In this bug, it seems that there is no information about old versions.
:gw, do you know if old version drivers also have the problem?
Comment 19•5 years ago
|
||
Just to satisfy my curiosity, I installed the latest stable Intel graphics driver version (26.20.100.7463) manually to my system, and the issue has gone away after re-enabling the gfx.webrender.compositor
flag. However, my Surface Book will attempt to re-install the old driver the next time I do a Windows Update.
Comment 20•5 years ago
|
||
The patch looks good to me (accepted in phab).
I think it's OK to blacklist only that driver version for now - we can easily extend it to other drivers if we get any other bug reports (just seen 2 reports, both with 6293 for now).
Nils, thanks for verifying that it is indeed fixed by an updated driver for you too. I'm going to try and find out if/when MS may push an updated driver for Surface books.
Updated•5 years ago
|
Comment 21•5 years ago
|
||
Of course! Happy to help squash bugs. :-)
Comment 22•5 years ago
|
||
Comment 23•5 years ago
|
||
Let's make sure we open a new bug blocking 73 to make sure that our blacklist is exhaustive enough. i.e. I'd be very surprised if this only affected the HD 520 and not the entire family.
Assignee | ||
Comment 24•5 years ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #23)
Let's make sure we open a new bug blocking 73 to make sure that our blacklist is exhaustive enough. i.e. I'd be very surprised if this only affected the HD 520 and not the entire family.
Created Bug 1602948 for it.
Assignee | ||
Updated•5 years ago
|
Comment 25•5 years ago
|
||
bugherder |
Description
•