Closed Bug 1066271 Opened 7 years ago Closed 7 years ago
Transaction by one frame for webgl on platforms without compositor fenching
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.
Depends on patches from bug 1066280
Attachment #8488205 - Attachment is patch: true
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
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
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.
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.
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 #8492426 - Attachment is patch: false
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: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.