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?
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.
Hi jwestervelt,
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