This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Which APIs will be blocked when throtting occurs

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?

Parents
    • 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?


    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.

Reply
    • 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?


    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.

Children