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

Why do the SDK samples tear when running on the Graphics and Compute Development on Samsung Chromebook instructions with EGL_BACK_BUFFER enabled?

Followed the instructions to enable the GPU drivers on a Samsung Chromebook (FB) and a bit surprised on how poor most of them appear. They seem to suffer heavily from tearing issues even with EGL_BACK_BUFFER enabled. Is triple buffering actually supported with FrameBuffers on Mali? Running the Mali demos on Imagination hardware doesn't seem to suffer from this which is quite surprising.

Parents
  • Tearing may be related to the GPU driver integration, but more commonly it occurs because the display controller driver has been built without vsync support enabled. Mali will render to whatever surfaces the window system gives us, but it is down to the window system / display controller driver to mange a tear-free vsync-enabled buffer swap; that's out of our control.

    > Is triple buffering actually supported with FrameBuffers on Mali?


    Yes, provided the window system supports it, but please don't don't confuse double buffer and triple buffering with sync-locked swaps - you can do tear-free rendering without triple buffering. What triple buffering does provided is better performance if you are running slower than the panel refresh rate, but it is not required simply to avoid tearing - you can do that with double buffering.


    I'll check with our BSP team which has published the pre-built development binaries to check what should be enabled on the binaries provided here ...


    http://malideveloper.arm.com/develop-for-mali/features/graphics-and-compute-development-on-samsung-chromebook/


    ... but it is likely to be after Christmas as most of that team is now on vacation.


    Hope that helps,

    Pete


Reply
  • Tearing may be related to the GPU driver integration, but more commonly it occurs because the display controller driver has been built without vsync support enabled. Mali will render to whatever surfaces the window system gives us, but it is down to the window system / display controller driver to mange a tear-free vsync-enabled buffer swap; that's out of our control.

    > Is triple buffering actually supported with FrameBuffers on Mali?


    Yes, provided the window system supports it, but please don't don't confuse double buffer and triple buffering with sync-locked swaps - you can do tear-free rendering without triple buffering. What triple buffering does provided is better performance if you are running slower than the panel refresh rate, but it is not required simply to avoid tearing - you can do that with double buffering.


    I'll check with our BSP team which has published the pre-built development binaries to check what should be enabled on the binaries provided here ...


    http://malideveloper.arm.com/develop-for-mali/features/graphics-and-compute-development-on-samsung-chromebook/


    ... but it is likely to be after Christmas as most of that team is now on vacation.


    Hope that helps,

    Pete


Children
No data