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

Mali-Txxx performance

Hi,

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 http://pastebin.com/Qzrh51Yv 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?

Thanks.

Parents
  • "something in the reference integration" - can you explain this a bit please?

    You basically seem to have covered what I was thinking - there are lots of options around management of surface memory and how that is moved around the system, how that interacts the with dmabuf kernel APIs for CPU-GPU memory coherency. It's one area where Linux is improving, but is still generally "a bit of a mess" and very possible to end up with a set of components which are functional, but doing more work than needed around mapping or cache flushing of buffers. I've never use the board in question, so I'm not entire sure how the buffer integration has been done, but this is an area where I know our direct licensees have had issues.

    I try to stay away from X11 because of the above issues and would love if the fbdev drivers would have decent performance.

    Yes, I agree. There is no real reason for the fbdev drivers to be as slow as they are; I'll definitely follow up with our BSP team to get this sorted.

Reply
  • "something in the reference integration" - can you explain this a bit please?

    You basically seem to have covered what I was thinking - there are lots of options around management of surface memory and how that is moved around the system, how that interacts the with dmabuf kernel APIs for CPU-GPU memory coherency. It's one area where Linux is improving, but is still generally "a bit of a mess" and very possible to end up with a set of components which are functional, but doing more work than needed around mapping or cache flushing of buffers. I've never use the board in question, so I'm not entire sure how the buffer integration has been done, but this is an area where I know our direct licensees have had issues.

    I try to stay away from X11 because of the above issues and would love if the fbdev drivers would have decent performance.

    Yes, I agree. There is no real reason for the fbdev drivers to be as slow as they are; I'll definitely follow up with our BSP team to get this sorted.

Children