Closed Bug 1453991 Opened 6 years ago Closed 23 days ago

Performance regression when turning off DirectComposition

Categories

(Core :: Graphics: WebRender, defect, P5)

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jrmuizel, Unassigned)

References

Details

Attachments

(1 file)

Today, I checked MotionMark score on my Win10 PC(P50). I was surprised that the score of "WebRender without DirectComposition" was too low. I disabled DirectComposition by "gfx.webrender.dcomp-win.enabled;false".

- Firefox nightly(CompositorD3D 11): 90-100
- Firefox nightly(WebRender with DirectComposition): 145-160
- Firefox nightly(WebRender without DirectComposition):6-12

By the way, the scores became better with "Windows 10 Spring Creators Update".
We need to understand why this is the case to be able to have the flexibility to disable DirectComposition if necessary.
Assignee: nobody → sotaro.ikeda.g
Priority: -- → P1
I checked past MotionMark scores on my Win10 PC(P50) by disabling DirectComposition. The scores were a bit better, but basically always very bad. For only a short period, there was a case that the score was very good. At the time, DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL was enabled temporarily. But DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL was soon disabled by Bug 1435995. We might avoid this problem by using CompositorWindow.
When we do not use DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL nor DirectComposition, WebRender might need partial rendering update to get better performance like multiple documents usage.
By Comment 2, the performance problem might be caused by hitting memory bandwidth.
(In reply to Sotaro Ikeda [:sotaro] from comment #2)
> But DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL was soon disabled by Bug 1435995. We might
> avoid this problem by using CompositorWindow.

I checked it locally. When we reset GPU process, I did not see the problem of  Bug 1435995. But if we did not reset GPU and just fallback to normal compositor, CompositorWindow usage did not work :( The problem of Bug 1435995 happened even after destroying CompositorWindow.
I do not have anything else to do in this bug for now.
Assignee: sotaro.ikeda.g → nobody
Priority: P1 → P3
Priority: P3 → P4
Jeff, what's the status of this?  Is it still an issue?
Flags: needinfo?(jmuizelaar)
Sotaro or Matt, is there anything we should be worrying about with DirectComposition on/off. I'm not sure what the current state of things is.
Flags: needinfo?(jmuizelaar) → needinfo?(sotaro.ikeda.g)
Flags: needinfo?(matt.woodrow)
With DirectComposition, we're using DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL to present buffers, without it we're using DXGI_SWAP_EFFECT_SEQUENTIAL.

Flipping buffers to present instead of copying uses less memory bandwidth and has better performance. We weren't able to figure out how use the flip model without DirectComposition because of bug 1435995.

It's possible that we could figure out a solution, but it's probably ok to rely on having DirectComposition for now.
Flags: needinfo?(matt.woodrow)
(In reply to Jeff Muizelaar [:jrmuizel] from comment #8)
> Sotaro or Matt, is there anything we should be worrying about with
> DirectComposition on/off. I'm not sure what the current state of things is.

Performance of WebRender + DXGI_SWAP_EFFECT_SEQUENTIAL is still not good. If we want to use DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL without DirectComposition, it might be possible with CompositorWindow in GPU process. There is bug 1435995. Then we need to make sure CompositorWindow is not reused during disabling WebRender.

On Win10, we could normally use use DirectComposition. Then it seems not necessary for now. And if we do not use DirectComposition, we could not use further performance optimization of using DirectComposition.
Flags: needinfo?(sotaro.ikeda.g)
WebRenderAllQualified seems not check Windows version.

:jrmuizel, do we enable WebRender on non-Win10 PC?
Flags: needinfo?(jmuizelaar)
Attachment #9016209 - Attachment is patch: true
Attachment #9016209 - Attachment mime type: application/octet-stream → text/plain
(In reply to Sotaro Ikeda [:sotaro] from comment #11)
> WebRenderAllQualified seems not check Windows version.
> 
> :jrmuizel, do we enable WebRender on non-Win10 PC?

gfx.webrender.all.qualified: https://hg.mozilla.org/mozilla-central/rev/67d5b919af15#l7.29
Other vendors than Nvidia and other Windows versions than 10 are unqualified.

Battery unqualified: https://hg.mozilla.org/mozilla-central/rev/162af260bace

Old Nvidia unqualified: https://hg.mozilla.org/mozilla-central/rev/8bf46e3c0767

bug 1475355 comment 3: Following vendors are probabaly still qualified on all Windows versions: Microsoft, Parallels & Qualcomm
https://searchfox.org/mozilla-central/rev/65f9687eb192f8317b4e02b0b791932eff6237cc/widget/GfxDriverInfo.h#111-113
https://hg.mozilla.org/mozilla-central/rev/8bf46e3c0767#l1.15 makes sure we have Nvidia. I'll remove the other vendor blacklisting.
Flags: needinfo?(jmuizelaar)
Priority: P4 → P5

(In reply to Jeff Muizelaar [:jrmuizel] from comment #0)

Today, I checked MotionMark score on my Win10 PC(P50). I was surprised that
the score of "WebRender without DirectComposition" was too low. I disabled
DirectComposition by "gfx.webrender.dcomp-win.enabled;false".

  • Firefox nightly(CompositorD3D 11): 90-100
  • Firefox nightly(WebRender with DirectComposition): 145-160
  • Firefox nightly(WebRender without DirectComposition):6-12

By the way, the scores became better with "Windows 10 Spring Creators
Update".

MotionMark score was still not good enough on intel Win10 pc. But it became a lot better compared to comment 0, since Bug 1528865 fix.

  • Firefox nightly(WebRender with DirectComposition): around 280
  • Firefox nightly(WebRender without DirectComposition):around 120
Depends on: 1528865
Severity: normal → S3
Status: NEW → RESOLVED
Closed: 23 days ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: