Is there a guide anywhere on getting hardware acceleration working properly on the Samsung Chromebook 2 or the Hardkernel ODroid XU3? These devices use the Mali T628. I have followed the guide at Graphics and Compute Development on Samsung Chromebook - Mali Developer Center Mali Developer Center , however the performance is lackluster. My suspicion is with the armsoc DDX driver. I believe that the guide was written with regards to the older Samsung Chromebook that used the Mali 400.
es2info shows that the system is not using mesa software rendering. I obtain about 200fps with es2gears, and when the window is enlarged, the framerate drops to about 30fps. The biggest problem is with 2D performance. I realize that the Mali devices are not 2D, but that the driver should be passing on the 2D operations to 3D via Glamor or the like. Moving windows such as a web browser around on the desktop results in very poor performance and user interface latency.
Is there a different xf86 driver that should be used with the T628?
The older Samsung Chromebook actually uses Mali T604. I installed the Mali binary drivers on Ubuntu and noticed a big 3D perf improvement over Mesa, but not quite the jump I was expecting.
I haven't gotten my hands on a Samsung Chromebook 2 yet but the mechanics of getting the OSS kernel driver and closed source binary blob installed and running on either Chromebook 2 or Chromebook should be very similar, especially if you're using the same ARM Ubuntu distribution.
I suspect there's a perf issue somewhere in the software stack as ChromeOS 3D (and 2D) perf is actually pretty decent.
Hi jwestervelt,
We are already investigating the possibility to adapt our instructions for the newer Samsung Chromebook 2 devices, including any binary driver changes that may be needed.
Please bear with us as we continue investigating this.
We will notify in this discussion as soon as possible when we are ready to release.
Unfortunately I cannot commit to an ETA for you, so please check back periodically.
Kind Regards,
Michael McGeagh
Michael,
Thank you for the update. Let me know if you need any testing assistance. I am primarily a Gentoo Linux user, and am currently working on getting a set of kernel patches together to add support for the Chromebook2 to the HMP (GTS) enabled kernels that Linaro put out. Seems as if the device tree source files for the Chromebook are absent in that branch. I'd be happy to test the revised Mali instructions against an upgraded kernel in case anyone wants to upgrade from 3.8.11. I'd also like to use the revised as a starting point for writing a similar guide for Gentoo, Arch, and Debian.
Jason
I see that the guide has been updated to include the XE503C32 device. I followed through with the guide and managed to get X11 up, but the 2D performance is absolutely horrid, to the point that it is not useable. Is there some setup that is required to get decent X performance in 2D? Dragging a window and getting less than 1FPS is pretty bad.
The window manager you are using probably does not have a GLES backend, so is falling back to software rendering and horrible perf. There are some GLES enabled window managers available, but the packaged versions tend to depend on mesa. If you can work around this by somehow not installing that dependency, or building from source, etc, then this should give better perf. X11 GLES applications should run with expected perf.
Hth,
Chris
It is also worth remembering that the Mali GPU is a 3D GPU, and not a 2D HW blitter engine. 2D windowing operations should take advantage of the 2D HW block in a device, if the BSP supports this, however this is not controlled by ARM and so our public BSP does not have this support included. As Chris has already pointed out, an easy way to overcome this is to use a windowing system that uses OpenGL ES API instead to render all parts of the UI, 2D and 3D. Then this will utilise the GPU for all operations and you will get hardware accelerated performance.
I hope this helps,
Further to what chrisvarns and mcgeagh have said, you can take a look at my answers to other questions Mali hardware acceleration on ubuntu on Chromebook and I have few questions about guide which is Graphic and Compute development on Samsung chromebook.
OpenBox, the environment installed when the image is created has no hardware acceleration hence the very poor performance when interacting with the desktop such as dragging windows. The 3d GLES content running within X windows WILL however be accelerated. If you would like a hardware accelerated desktop environment, I have seen that KDE has a GLES implementation of KWIN https://wiki.archlinux.org/index.php/KDE#Configure_KWin_to_use_OpenGL_ES. This may be of interest if you can get it working as it *should* provide the high performance desktop environment you want. I haven't looked at it myself and so am unsure of the effort required to get it working, or the performance it will give. This is, however, something I'd be interested in looking into and that we could potentially include as part of the developer guide in future.
Hope this helps,
Rich
Thanks for the input. I "managed" to get KWIN working, even with composition, but I ran into some rather severe limitations due to how the userland libraries are distributed. As it stands, `ld` cannot find libEGL and libGLES* because the userland binaries are distributed as a single functional libmali.so with a stub for libEGL/libGLES*. The issue, I suspect, is that the resulting SONAME is incorrect and linking fails... at one point I think that the library files were presenting themselves as libmali.so, but I cannot currently get an SONAME out of the library.
I am forced to switch back to the mesa libEGL/libGLES* libraries during compilation, and after switching back, i do get some performance issues/image corruption with things built in this manner. Is there a workaround? I'd try to manually manipulate the SONAME in the binary, but I can only shorten the name, so i'd be out of luck when it came to libGLESv1_CM and libGLESv2.
I have seen this myself in the past, and have raised it to the relevant driver team internally.
I cannot give an ETA however, but can provide a workaround that seemed to work for me.
Simply remove the stub files (or mv them) and replace them with symbolic links to libmali.so
e.g.
ln -s libmali.so libOpenCL.so
As libmali.so is monolithic, this will work for EGL and the GLES stubs too.
Feel free to contact us if you have further questions.