Closed
Bug 988573
Opened 11 years ago
Closed 7 years ago
WebGL buffer present machinery calls into glReadPixels.
Categories
(Core :: Graphics: CanvasWebGL, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: jujjyl, Unassigned)
References
Details
(Whiteboard: [games] webgl-perf)
Attachments
(1 file)
1.04 MB,
image/png
|
Details |
Profiling WMW on Firefox OS Leo device (built and flashed today, 1.5.0.0 trunk master branch), it looks like presenting a GPU-rendered frame involves calling glReadPixels at the end of the frame rendering, and a CPU-blit to composit to screen.
The WMW game runs a web page that is more or less just one WebGL <canvas> element, which is fullscreen all the time, pixel-perfect with aspect-ratio-corrected. In that case, rendering with WebGL to FBO 0 should directly render to the default screen backbuffer, and not route through an offscreen backbuffer that involves GPU->CPU read plus a blit, or even an extra 2D GPU->GPU composit.
Attached an image of result from profiler showing the situation. The glReadPixels part consumes 16% of the whole frame time (~8 msecs), which is mostly spent in waiting for the GPU to finish rendering the current frame. This means we are introducing a CPU-GPU sync point at the end of each frame, so we are both CPU and GPU -bound at the same time in WMW because of the bubble.
Is this something that is happening by oversight, or is this something that will be difficult to avoid?
Reporter | ||
Updated•11 years ago
|
Whiteboard: [games] webgl-perf
Comment 1•11 years ago
|
||
This ReadPixels calls is intentionally blocking --- it's an optimization to avoid calling glFinish() instead. The problem is that we don't have proper fences.
Here it is:
http://dxr.mozilla.org/mozilla-central/source/gfx/gl/SharedSurfaceGralloc.cpp#138
in SharedSurface_Gralloc::Fence().
Can you replace this ReadPixels call by
mGL->fFinish()
and report whether this is faster or slower?
Reporter | ||
Comment 2•11 years ago
|
||
Check, I'll build and try with that.
Btw, why do we need to fence in the first place? If we are triple-buffering, can we continue to running the next requestAnimationFrame immediately without waiting for the blit to finish as long as we have free unused buffers in the queue? i.e. call eglSwapBuffers() or the equivalent, and continue on to running the requestAnimationFrame block for the next frame.
Reporter | ||
Comment 3•11 years ago
|
||
With mGL->fFinish() the performance is pretty much identical, 15.0% of time spent inside that call.
We need to fence because when we present with HWComposer on this hardware, it was scanning out (I believe) a buffer that the GPU wasn't done rendering to. With proper GPU fence support, it would have a fence to do a proper wait on the buffer all on the GPU/HWC side. This was intended to be a temporary workaround until we have proper support, and we have most of the machinery in place now.. we just need to see how to implement those fences.
Comment 6•11 years ago
|
||
(In reply to Jeff Muizelaar [:jrmuizel] from comment #5)
> See bug 91744 for where we turned the readpixels on
Bug 917444 seems a correct bug.
Comment 7•11 years ago
|
||
Bug 767484 seems to fix the problem on gonk. Bug 767484 have some dependent bugs. I am going to fix them.
Reporter | ||
Comment 8•11 years ago
|
||
The issue https://bugzilla.mozilla.org/show_bug.cgi?id=1008216 on B2G might be caused by the sync issue mentioned in this bug. Sorry to ping, but has there been any progress in this bug?
Comment 9•11 years ago
|
||
A lot of fence related work is being done or has been done. Can you still reproduce this bug on the trunk? What Android version is Leo device running?
Comment 10•11 years ago
|
||
Sotaro, are we still using this workaround on JB and KK devices?
Flags: needinfo?(sotaro.ikeda.g)
Comment 11•11 years ago
|
||
(In reply to Milan Sreckovic [:milan] from comment #10)
> Sotaro, are we still using this workaround on JB and KK devices?
Waiting Bug 999694 landing state. If is is landed next Bug 1001417 need to fix.
Flags: needinfo?(sotaro.ikeda.g)
Comment 13•10 years ago
|
||
As far as I understand, we're not doing this on any target devices for 2.0, but only on the ICS ones. Removing 2.0 blocker status.
blocking-b2g: 2.0+ → ---
Comment 14•10 years ago
|
||
ICS phone that supports egl sync does not use glReadPixels for fencing. Bug it causes Rendering problem on hamachi. It is Bug 1022205.
Reporter | ||
Comment 15•7 years ago
|
||
This was a performance bug for the Where's My Water? Firefox OS project, which was optimized and shipped on performance target. I think this one did not get fixed in the end, but no longer matters.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•