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?
Hi jwestervelt,
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.
Kind Regards,
Michael McGeagh