With WebRender, textures tend to remain locked for two extra frames
Categories
(Core :: Graphics: WebRender, defect, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox72 | --- | fixed |
People
(Reporter: nical, Assigned: bobowen)
Details
Attachments
(1 file)
This makes us hit unhappy paths in various texture recycling systems, such as https://searchfox.org/mozilla-central/rev/ebe492edacc75bb122a2b380e4cafcca3470864c/gfx/layers/PersistentBufferProvider.cpp#309 is hit a lot unless the threshold is bumped from 4 to 6 which is a lot.
Part of the issue is WebRender's pipelining which adds a frame of latency in general.
Part of the issue comes from our use of triple buffering in the window presentation, and how we assume the worst case when we wait before unlocking textures, see https://searchfox.org/mozilla-central/rev/ebe492edacc75bb122a2b380e4cafcca3470864c/gfx/webrender_bindings/RenderCompositorANGLE.cpp#588
It would be nice if instead of waiting for N frames to complete we'd poll the amount of pending frames using some GPU synchronization mechanism without blocking. In a lot of cases we would be able to read-unlock textures earlier.
Cheers to :bobowen for finding the issue and its causes.
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 1•5 years ago
|
||
|
|
Assignee | |
Comment 2•5 years ago
|
||
This replaces mUpdatesCount in AsyncImagePipelineManager, which was really how
many times NotifyPipelinesUpdated was called with aRender == true. I think this
makes the release logic clearer as it is more explicit.
It also changes things for RenderCompositorANGLE, so that we check to see if
any other frames have completed even if we don't want to wait for them.
Depends on D51063
Pushed by bobowencode@gmail.com: https://hg.mozilla.org/integration/autoland/rev/fbe264cd2d82 Add a RenderedFrameId to RenderCompositor and use it to control release of textures. r=sotaro
|
||
Comment 4•5 years ago
|
||
| bugherder | ||
Description
•