Closed Bug 1608741 Opened 2 years ago Closed 2 years ago

Fix reftest failures in DirectComposition mode with virtual surfaces.

Categories

(Core :: Graphics: WebRender, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: gw, Assigned: gw)

References

Details

Attachments

(3 files, 1 obsolete file)

No description provided.
Assignee: nobody → gwatson

In some cases, DC shows inaccuracies (pixel values might be off by
1 or 2) in reftests when virtual surfaces API is enabled. This is
due to the DC root visual having bilinear filtering enabled.

We never need this mode anyway, as the DC surfaces are always
rasterized at 1:1 ratio, so we can just enable the nearest
neighbor interpolation mode, which is a slight performance win too.

Try run with the fix is still pending [1], but this fixes the reftest failures on my locally machine reliably.

[1] https://treeherder.mozilla.org/#/jobs?repo=try&revision=8105abaf98f365166a7a480dfda1d2b504d5fed7

Blocks: 1592509

(In reply to Glenn Watson [:gw] from comment #1)

Created attachment 9120387 [details]
Bug 1608741 - Fix reftest failures in DirectComposition mode with virtual surfaces.

In some cases, DC shows inaccuracies (pixel values might be off by
1 or 2) in reftests when virtual surfaces API is enabled. This is
due to the DC root visual having bilinear filtering enabled.

I wonder whether this is exacerbated by the large coordinates we use for virtual surfaces. It would be interesting to see if these artifacts happen less frequently with a smaller VIRTUAL_OFFSET.
For the remaining failures, do we know why these artifacts happen differently for the test and the reference? Do the two cases have different tile positions or tile opaqueness?
I think it's important to fix this rather than fuzzing it away. I would imagine that for example people who write layout reftests would be very confused if they needed to add fuzz to their test even if they use only graphics features that do not require fuzz traditionally. And worse, it would be a big waste of time if they started debugging the cause of the fuzz, only to find out that the tile content was perfectly fine but the failure was introduced at the OS compositing level.

(In reply to Markus Stange [:mstange] from comment #3)

(In reply to Glenn Watson [:gw] from comment #1)

Created attachment 9120387 [details]
Bug 1608741 - Fix reftest failures in DirectComposition mode with virtual surfaces.

In some cases, DC shows inaccuracies (pixel values might be off by
1 or 2) in reftests when virtual surfaces API is enabled. This is
due to the DC root visual having bilinear filtering enabled.

I wonder whether this is exacerbated by the large coordinates we use for virtual surfaces. It would be interesting to see if these artifacts happen less frequently with a smaller VIRTUAL_OFFSET.
For the remaining failures, do we know why these artifacts happen differently for the test and the reference? Do the two cases have different tile positions or tile opaqueness?
I think it's important to fix this rather than fuzzing it away. I would imagine that for example people who write layout reftests would be very confused if they needed to add fuzz to their test even if they use only graphics features that do not require fuzz traditionally. And worse, it would be a big waste of time if they started debugging the cause of the fuzz, only to find out that the tile content was perfectly fine but the failure was introduced at the OS compositing level.

Setting VIRTUAL_OFFSET to a small number was the first thing I tried, and it had no effect, unfortunately (I tried 8192 and also 0). I also tried removing all the calls to Trim which is the other virtual-surface-specific API that we use, and that had no effect either.

I suspect what is happening is that the tiles with valid pixels end up being at different locations within a surface (due to allocation patterns), and that texturing from those different UVs results in very slight inaccuracies in some cases. I suspect this because we see the exact same behavior in wrench with the texture cache on various rasterizers (we clear the texture cache between wrench tests to mitigate this).

Having said that, I totally agree that fuzzing is not desirable here. I'm going to spend another 1-2 days investigating it to try and determine the exact root cause - it might simply be that we're not correctly rounding a value passed to DC somewhere, or something like that, hopefully!

Attachment #9120387 - Attachment is obsolete: true

There's no need for bilinear interpolation of DC surfaces. This
fixes a lot of the fuzziness issues when using virtual surfaces,
so it makes sense to land it now while continuing to investigate
the remaining issues.

There are a number of issues with the current gradient dithering
implementation, that cause many test failures and also fuzziness
rendering when enabling DirectComposition virtual surfaces. In
particular, the dither result is dependent on the offset of the
update rect within a render target.

For now, this patch disables gradient dithering by default. This
gives us:

  • A heap of new test PASS results (or reduced fuzziness).
  • Fixes a number of non-deterministic fuzziness bugs with DC.
  • Improves performance of gradient rendering by a reasonable amount.

We can fix gradient dithering as a follow up, and re-enable if/when
we find content that would benefit from it significantly (we may
be able to improve gradients in other ways than dithering too).

Try run for the Part 2 patch - https://treeherder.mozilla.org/#/jobs?repo=try&revision=5891ab71fadfb511dedf7491bce278d99a98067f

Looks good, I think. It's possible I missed a platform that is affected by the fuzziness changes. If so, please back out and I'll fix up tomorrow morning.

I confirmed that there is an intermittent failure in one of the newly enabled tests that also occurs on m-c, so I will mark that test as [FAIL,PASS] for now. Filed as https://bugzilla.mozilla.org/show_bug.cgi?id=1610662.

See Also: → 1610662
Pushed by gwatson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/f758f235dd70
Part 2 - Disable dithering on gradient primitives. r=sotaro,nical

This patch adds fuzziness for three tests that have intermittent
fuzziness issues when DirectComposition virtual surfaces are enabled.

In each of the cases, there is a dashed border style, which has
occasional rasterizer accuracy issues. Each of the tests has a
max fuzziness of 0-1 value, with 0-10 pixels, so it's a minimal
amount of difference between the images.

Given this, we can add fuzziness to allow enabling the native
compositor mode, and investigate these as follow ups.

Attachment #9122544 - Attachment description: Bug 1608741 - Add fuzziness for some tests with virtual surfaces. → Bug 1608741 - Part 3 - Add fuzziness for some tests with virtual surfaces.
Pushed by gwatson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/b723d635ae01
Part 3 - Add fuzziness for some tests with virtual surfaces. r=jrmuizel
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.