mali: detect and workaround mismatch between back and front buffers
After window creation or resize, the mali blob on the client side requests two dri2 buffers (for back and front) from the ddx. The problem is that the 'swap' and 'get_buffer' operations are executed out of order relative to each other and we may have different possible patterns of dri2 communication: 1. swap swap swap swap get_buffer swap get_buffer swap swap ... 2. swap swap swap get_buffer swap swap get_buffer swap swap ... A major annoyance is that both mali blob on the client side and the ddx driver in xserver need have the same idea about which one of there two buffers goes to front and which goes to back. Older commit https://github.com/ssvb/xf86-video-fbturbo/commit/30b4ca27d1c4 tried to address this problem in a mostly empirical way and managed to solve it at least for the synthetic test gles-rgb-cycle-demo and for most of the real programs (such as Qt5 applications, etc.) However appears that this heuristics is not 100% reliable in all cases. The Extreme Tux Racer game run in glshim manages to trigger the back and front buffers mismatch. Which manifests itself as erratic penguin movement. This patch adds a special check, which now randomly samples certain bytes from the dri2 buffers to see which one of them has been modified by the client application between buffer swaps. If we see that the rendering actually happens to the front buffer instead of the back buffer, then we just change the roles of these buffers. Signed-off-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>
Please register or sign in to comment