Looking at this post
Graphics and Compute Development on Samsung Chromebook « Mali Developer Center Mali Developer Center
I have see that is possible to have Mali GPU hardware acceleration on Samsung ARM Chromebook with Ubuntu.
On the post you guide all the process to prepare an sd card to install ubuntu with mail support on chromebook, could you provide even the imagefile of the generated sd card?
Thanks
Hi yebyen,
Please see my response in this thread: I have few questions about guide which is Graphic and Compute development on Samsung chromebook.
Briefly, the install script doesn't aim to provide users with a fully hardware accelerated desktop environment, this is because almost no desktop environments on linux support OpenGLES as a back-end renderer. OpenBox which is installed during the setup process itself is NOT hardware accelerated and so performance when dragging windows around is poor as the compositing is done on the CPU. If you are running OpenGLES content within windows, however, this WILL be hardware accelerated to render which is the goal.
Having taken a brief look, I can see that KDE now seems to have a GLES implementation of kwin (https://wiki.archlinux.org/index.php/KDE#Configure_KWin_to_use_OpenGL_ES) which *should* give you the high performance desktop environment you seem to want if you are able to investigate this and get it working. This is something that I would be interested in looking into and potentially in future we could update the guide to install this by default. I do believe that the enlightenment desktop environment does also support hardware accelerated rendering using OpenGLES but I believe this is very much under active development. The main goal of the Chromebook developer guide is to quickly and easily create an environment on the chromebook where developers can run and test their GLES applications on linux running on Mali hardware.
As for the issues your originally experienced, the build script doesn't set up wifi in its current form and it is stated on the guide page under requirements: USB-Ethernet adapter to enable network communications. Adding wifi support from first boot is something we would like to add, but we haven't got around to it yet.
With regards to issues with X starting, I can only assume that early in the process you installed, whether as a dependency or not, mesa libs that did conflict with the mali binaries installed, I'm glad you appear to have fixed this issue though.
Hope this helps,
Rich
OK, so I am not seeing anything that I'm not expected or supposed to be seeing. Good.
I did not know about chromium-mali-opengles from the Bodhi project. Good tip also. Thanks. I still have high hopes for E19, the build script takes a decent while and is for trusty (14.04) while I already moved on with do-release-upgrade -d to utopic (14.10), so I haven't succeeded at building it yet as some minor changes as expected are needed from the trusty script to build it from git.
Of course this is totally out of scope for this thread, but I may now also try KDE from your advice. E19 had a stable release in September with "full wayland support" (which I may have misread as "much improved/fully supported OpenGLES compositor implementation".)
I had indeed installed mesa as you suspected, it was pretty easy to move the libraries out of the way once I found the specific list of libs I shouldn't have been linking with (and which versions were asked for by name in the software I was trying to use with now broken library links). Not sure how to build glmark2-es2 or es2_info/es2gears, they pulled in mesa when I installed mesa-utils-extra, the only libraries that seemed to be in conflict were the ones in /root/mali and those are "drop-in replacement" for the es2 libs of mesa.
Thanks for confirmations, I think you addressed all of the remaining oddities I was seeing, and everything is now as it should be expected to be! The tutorial should really take you all the way up to running (literally anything at all) with acceleration, because it ends at "type startx" and from what you've told me, there is nothing even remotely accelerated on or near the screen when you finally get to this point. My natural inclination once learning that plain GL is not supported was to install es2gears to see if it's really working, and that was exactly the wrong thing to do because it necessarily pulls in mesa.
Maybe that's too much garden path thinking, and you want that maybe your target audience should really be able to go on the forums and figure this out. I understand you are promoting Mali to devs, not Samsung Chromebook to end users, but nobody else can provide the drivers and even regular users need drivers sometimes bonus points to the thread you linked because you all mentioned "feh"
Works for me now. Hopefully this thread can also help someone else get here, too.
Thanks for the feedback, glad it's all working now. Enough people have tripped over the mesa thing that we should address it in the guide, and I agree we could do more in the guide to confirm a working setup. I'll pass this on to the relevant people.
nobody else can provide the drivers and even regular users need drivers sometimes
Strictly speaking there are people downstream of us that could do this (Samsung/Google in this case) but supporting Linux environments tends to be quite far down the priority list. We do this in an effort to provide an easily accessible, relatively cheap development platform to those wishing to develop GLES applications on Mali hardware, but we're by no means the gatekeepers to providing such support!
bonus points to the thread you linked because you all mentioned "feh"
Are you a dev?
Cheers,
Chris
... nobody else can provide the drivers and even regular users need drivers sometimes Strictly speaking there are people downstream of us that could do this (Samsung/Google in this case) but supporting Linux environments tends to be quite far down the priority list. We do this in an effort to provide an easily accessible, relatively cheap development platform to those wishing to develop GLES applications on Mali hardware, but we're by no means the gatekeepers to providing such support! bonus points to the thread you linked because you all mentioned "feh" Are you a dev? Cheers, Chris
...
I am very computer sometimes, others not so much. It's true that there is not much help from Samsung or Google on this front! I was very glad to find the drivers here, even more now that I start to see how they are put together.
So far EFL compiled from git, the biggest hurdle is that -lGLESv2 and -lEGL are both stubs, missing everything you would normally expect to find in them with the actual functionality implemented in libmali.so, so everything that links either of those needs to -lmali as well or undefined symbol glTexImage2D, etc. Caught at configure time building EFL. That is why chromium from ubuntu doesn't access the acceleration features too, I'd assume, because it doesn't link in libmali.so.
I think it will work now, but there's an hour of compiling left maybe or more before I see, and it's time for bed now!
Kingdon
Well, performance is very good, in spite of something apparently not being configured correctly so it seems to have fallen back to software, now it's clearly not near as snappy as ChromeOS.
./configure --prefix=/usr/local --enable-harfbuzz --enable-image-loader-webp --enable-multisense --enable-xine --enable-xinput22 --with-opengl=es --enable-egl
is what I asked for to configure efl, mostly the same options as the options ubuntuhandbook/nineteen.sh would have passed, except for the last two
http://paste.ubuntu.com/9114197/
My extremely naive patch which got me past configure, I think what might be missing now is that the evas engine for egl is actually wayland only, and that is why I am where I am now. Nothing in this case seems to have actually been linked against EGL or GLESv2. Funny, configure would not let me proceed without proving I could link to them and that they had the right stuff (libmali.so). I guess that's because I asked it to...
Thanks for your help. It's all working now.