Closed
Bug 1066271
Opened 10 years ago
Closed 10 years ago
Delay LayerTransaction by one frame for webgl on platforms without compositor fenching
Categories
(Core :: Graphics: Layers, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: BenWa, Assigned: BenWa)
References
Details
Attachments
(7 obsolete files)
On platforms where we can't use the compositor to wait on the webgl we would like to add a frame of delay to let WebGL content resolve. Right now we just wait on the fence and run the CPU/GPU in lockstep.
If we're using an async transaction we can hold off the transaction and delay it until the next frame if it has a WebGL edit and the transaction is asynchronous.
Assignee | ||
Comment 1•10 years ago
|
||
Depends on patches from bug 1066280
Assignee | ||
Updated•10 years ago
|
Attachment #8488205 -
Attachment is patch: true
Assignee | ||
Comment 2•10 years ago
|
||
Implementing this on top of bug 1066280 is the right thing to do.
I have a prototype that works on Windows. We can render content where the game logic takes 16ms with a non trivial load on the GPU.
http://people.mozilla.org/~bgirard/webgl-tweak.html
On my desktop machine with 15.8ms, 300 trig:
Nightly: 36 FPS +-1
Prototype: 60 FPS solid
Depends on: 1066280
Assignee | ||
Updated•10 years ago
|
Summary: Delay LayerTranaction by one frame for webgl on platforms without compositor fenching → Delay LayerTransaction by one frame for webgl on platforms without compositor fenching
Assignee | ||
Comment 3•10 years ago
|
||
This delay transaction are now working. I couldn't see any race conditions. This is fencing properly.
I'm still a 2x speed improvement for the case where the GPU rendering time == rAF time (and the times are non trivial).
In my demo with 32ms CPU and 60k we get 15 FPS on nightly, 28 FPS with the patch.
Assignee: nobody → bgirard
Attachment #8488154 -
Attachment is obsolete: true
Attachment #8488205 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Assignee | ||
Comment 4•10 years ago
|
||
Attachment #8488885 -
Attachment is obsolete: true
Assignee | ||
Comment 5•10 years ago
|
||
Attachment #8488887 -
Attachment is obsolete: true
Assignee | ||
Comment 6•10 years ago
|
||
Attachment #8490381 -
Attachment is obsolete: true
Assignee | ||
Comment 7•10 years ago
|
||
Comment on attachment 8490429 [details] [diff] [review]
patch v2 (rebased + fixes)
Review of attachment 8490429 [details] [diff] [review]:
-----------------------------------------------------------------
::: gfx/layers/client/CanvasClient.cpp
@@ +464,5 @@
> // Use the new TexClient.
> mFrontTex = newTex;
>
> forwarder->UpdatedTexture(this, mFrontTex, nullptr);
> + GetForwarder()->DelayFrame(mFront);
Self note: Only do this if mFront is a angle surface.
Assignee | ||
Comment 8•10 years ago
|
||
Still need to work out the details of IMMEDIATE_UPLOAD && DEALLOCATE_CLIENT.
I'd like feedback on the overall approach before I start fixing the individual failures.
Attachment #8490429 -
Attachment is obsolete: true
Attachment #8492426 -
Flags: feedback?(matt.woodrow)
Assignee | ||
Updated•10 years ago
|
Attachment #8492426 -
Attachment is patch: false
Assignee | ||
Updated•10 years ago
|
Attachment #8492426 -
Attachment is obsolete: true
Attachment #8492426 -
Attachment is patch: true
Attachment #8492426 -
Flags: feedback?(matt.woodrow)
Assignee | ||
Comment 9•10 years ago
|
||
WONTFIX for now. It's not a great solution but it's a viable candidate if other solution don't pan out. Basically it's our backup plan.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•