For this article(Mali GPU: An Abstract Machine - Frame Pipelining - Graphics and Gaming blog - Graphics and Gaming - Arm Community), I have a question.
“blocking inside an EGL or OpenGL ES API function until the display consumes a pending buffer”
The throttling mentioned in this article will block EGL or ES API calls when throttling occurs. What are the specific APIs that will be blocked? Only eglSwapBuffers? Will other glDraw be blocked? Others?
"It depends" on Android version and driver version. Typically one of:
Peter Harris said:First draw call
First draw call to FBO0
The ones above are the result of the situation below？
“This throttling mechanism is normally provided by the host windowing system, rather than by the graphics driver itself. On Android for example we cannot process any draw operations in a frame until we know the buffer orientation, because the user may have rotated their device, changing the frame size. SurfaceFlinger — the Android window surface manager – can control the pipeline depth simply by refusing to return a buffer to an application’s graphics stack if it already has more than N buffers queued for rendering.”
And is the buffer mentioned in the context the framebuffer of opengl?
Peter Harris said:eglSwapBuffers()
The one above is the result of the situation below？
“This same scheme also limits the pipeline buffering if the graphics stack is running faster than the display refresh rate; in this scenario content is "vsync limited" waiting for the vertical blank (vsync) signal which tells the display controller it can switch to the next front-buffer. If the GPU is producing frames faster than the display can show them then SurfaceFlinger will accumulate a number of buffers which have completed rendering but which still need showing on the screen; even though these buffers are no longer part of the Mali pipeline, they count towards the N frame limit for the application process.”
No - it's not split like that, the same function will block on both, but different versions of the backend stack will block in difference places. In general I'd expect most recent implementations to block on first draw to FBO0, but I've not checked it on latest Android.
Sorry.I am even more confused. Can you provide some more detailed information? About the driver or related information?
I don't have anything more specific. For most applications it doesn't matter - there isn't anything you can really do differently given that exactly what blocks depends on version and vendor. If it does matter all you can really do it benchmark it on specific devices that you care about.
Also, worth looking at:
* https://developer.android.com/games/sdk/frame-pacing... which is a slightly better way of handling frame pacing.
View all questions in Graphics and Gaming forum