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?

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?

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.

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.

See bug 91744 for where we turned the readpixels on

(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.

Bug 767484 seems to fix the problem on gonk. Bug 767484 have some dependent bugs. I am going to fix them.

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?

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?

Sotaro, are we still using this workaround on JB and KK devices?

(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.

Great, let's target this for 2.0.

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.

ICS phone that supports egl sync does not use glReadPixels for fencing. Bug it causes Rendering problem on hamachi. It is Bug 1022205.

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.