Mali-Txxx performance


I have been using both the X11 and fbdev drivers (r4p0) on an Odroid-XU3 with Mali-T628, the kernel driver integrated by the vendor (Hardkernel) and the binary blob from armdeveloper website.

The performance was really bad - especially on fbdev, framerates were less than half than on X11. On X11, framerates were worse than on an Odroid-U3 with Mali400.

Now with the release of r5p0 drivers, early tests see a similar situation, unfortunately.

On r4p0-MaliT628 X11, I get just under 200fps on es2_gears, and ~55 glmark2 score. I've seen the results of Mali-T764 on the RK3288 board from and are similarly bad.

Is this something you are aware of?

On Mali-400, I get ~260 fps in es2_gears, and a glmark2 score of ~60. fbdev and x11 performance is similar.

But I would even be happy with these numbers in fbdev. es2_gears does not work on fbdev, but some of the apps I've been trying showed exceptionally poor framerates (15 in fbdev vs. 60 in X11) and were unusable.

On the forums, I remembered seeing a similar post with a benchmark on Arndale octa or Chromebook (can't remember exactly, T6xx in any case), where framerates were also smaller with fbdev drivers for the same app.

Is there any comment on the performance of fbdev vs. x11? Or the lack of 3D performance seen in the Txxx from various vendors?


Parents Reply
  • Hi Jasbir,

    Thanks, so we're at least using different kernels.  We've run our benchmarks using this Firefly 3.10 kernel branch:

    I don't think either of them is using DMA-BUF in fbdev, but the 3.14 Chromium kernel should definitely have it enabled in X11 as that's what Chrome OS uses, or at least has used until now.  It would still be good to know that really makes this fps difference in fbdev.  We might run our benchmarks again with 3.14 at some point, but please also let us know if you try 3.10 on your side and get different results.  Also, as fbdev uses memcpy which takes a fair amount of CPU usage and memory bandwidth, if the CPU is busy doing anything else at the same time then this may indirectly impact the graphics performance.

    Android kernels provide the ION framework which essentially does the same thing as DMA-BUF to share a buffer between the display and GPU drivers.  In principle, any modern kernel used in a production Android device will have ION enabled.  Some may use DMA-BUF, but none of them would want to use software memcpy...  The Mali user-side drivers are built for a specific windowing system, and the difference is mainly about how to set up the zero-copy by sharing the display buffer with the GPU driver.  For example, with DMA-BUF this is typically achieved by passing a file descriptor from the display driver to the GPU driver via user-space.

    Best wishes,


No data
More questions in this forum