Hi ,
Recently I tried to run the glmark2-es2 on Exynos 5422 Board of odroid.
The Mali Drivers version used was r4p1 for Mali T628 GPU and kernel version 3.19 rc1(same experiment was done with 3.10 kernel and 3.17 also)
For this I used Yocto distribution(dizzy 1.7.1) wih matchbox window manager first where glmark2-es2 score was very less - 18 FPS.
Then we changed the window manger to metacity in yocto and ran same gmlark2-es2 and score came out to be 65 FPS.
It was quite surprising as i thought the OpenEGL/Mali drivers performance depends on kernel configuration and performnace tunings done for Mali .
Is there any dependencies on window manger we chose also?
Hi abha,
To get optimal performance when running a GLES application in X11 you need one of the following:
- The application is configured to run in full-screen and is a top-level window (i.e., there will be a large performance impact if another window is rendered on top)
- The window manager is a GLES-compatible compositing window manager
Understandably it is not always possible/desirable to run applications in full-screen mode so the practical option is to use a compositing window manager. To my knowledge only Compiz (certain branches), KWin (4.x), Mutter (the GNOME 3's default window manager which is used by GNOME shell) and Ubuntu's Unity (which uses a modified version of Compiz) support compositing in GLES mode.
The main reason for the performance impact is because the armsoc driver doesn't make use of hardware blitter (which might not be present in an SoC) to transfer rendered frames from GPU to X11 windows. As a result all frames rendered using the GPU will have to be converted and copied to X11 windows using CPU. Using a GLES compositing window manager avoids this issue where the X11 window content is stored and rendered as a texture. In a non-composited environment the Mali driver takes a shortcut and renders directly to the display frame buffer -bypassing most of X11's processing- if it detects a full-screen, top-level GLES window.
Best regards,
Tu
I would argue that part of the problem is that most ARM licencees don't offer a 2D api out side of Android that can be used to implement X11 extension for blitting and other 2D operations. If you review the datasheets of the SOC you normally find a wealth of features available from their 2D graphics engine which sadly can't be used. The other complexity is that the 2D api most likely differ per ARM licencee which fragments any common approach for a generic driver. This is why you see EGL/GLES is used to implement 2D features even though the SOC may have native support in the silicon.
Hi Jasbir,
That is correct. Making use of the hardware blitter represents a big performance improvement when we scale up the surface dimension but it is a small portion of what the hardware theoretically can deliver. Unfortunately each OEM needs to implement the appropriate extension for X11, so far most of the efforts have been concentrated on Android.
It might be worth noting that aside from Intel and -to an extent- nVidia, no other graphics vendors to my knowledge provide full 2D acceleration for their binary X11 drivers.