PhysX and other middleware physics engines are used in a large majority of today’s video games because they free game developers from having to write their own code that implements classical mechanics (Newtonian physics) to do, for example, soft body dynamics.
When I first heard about the lima driver it was over at limadriver.org, at that time I didn’t had much interest as I was more of an RPi FanBoy but also the VC4 Opensource driver was coming along fairly well that that seemed more interesting and in contrast the development on the lima driver had gone a bit stale tbh.
Fast forward to a few months back I saw this post from Phoronix, about the re-initiation of work on the Lima driver by Qiang Yu, but again reading the lines “So far this Mesa Gallium3D driver can run a simple OpenGL triangle draw application” put my interest on hold… until two weeks back.
Experiment 2) Off-Screen Rendering
Now when I finally decided to go ahead and try this out, I didn’t had any device that would work out of the box with the existing build systems (as it later turns out I did) that included buildroot for Allwinner based devices and Yocto for Amlogic SoC. So naturally I had to enable a close relative and that turned out to be the Banana Pi M1+ since CubieBoard2 was already enabled with lima in build root and both the boards use the Allwinner A20 SoC.
So they way Mali GPUs work in general, and this is afaik, they are used for rendering ONLY, all the display work is done by a separate display processor usually specific to the SoC vendor (like sun4i-drm for Allwinner, mason-drm for Amlogic etc.) unless they are using one build by Arm. So at a given time there are two DRM(Direct Rendering Infrastructure + Kernel Modsetting + a bunch of other things) drivers running one for the “Display Processor” for the actual video output and a second one for the actual GPU for rendering. And LIMA tackles the latter one, the one that does all the rendering.
So now that you know this you should also know that I was completely unaware of this situation, so I merrily went ahead and enabled the lima-drm driver for Banana Pi and…. drum roll…. kmscube crashed 🙁 (for obvious reasons). However it worked great off-screen and this is how that looks:
Experiment 3) On-Screen Rendering and Nano Pi M1
NOW after a few emails back and forth I am aware of the situation. So before I went ahead and enabled the sun4i-drm, I really wanted to see Lima working, and still unaware of the fact that I do actually own a verified board, I went ahead and bought the Nano Pi M1 since Qiang Yu uses that on his end and it was really cheap.
So it did end up working really well, and I also ended up adding support for the Banana Pi M1+
Experiment 4) Khadas Vim, Mali 450, and GLMark2
NOW I FINALLY REALIZE that I have the Khadas Vim that has the Amlogic S905X which is verified, I setup a yocto build for that and… drum roll… It wont boot 🙁
Again a few emails back and forth and we found out the issue was with wrong root partition path, solved that and now kmscube runs smoooooth.
But now I want to sun something a bit more “real world” because as exciting it is to people like me, a spinning cube on a grey background doesn’t speak out to the general public as spinning horse, cat and jellyfish do. Ofc I am talking about glmark2. After coming across this thread on the mesa-lima repo, I was able to get bits and pieces of GLMark2 working and it looked Coool…
Here is a small demo of kmscube and whatever-runs-in-GLMark2: 400 vs 450
And now I am off to try and enable more boards and possibly SoC(s)…
Qiang Yu: for LIMA and helping out with Banana Pi M1+
I know I don’t do a lot of blog posts like this one, most of them are just extra info on the video I upload, however that is planned to change and hopefully it looks more like a blog.
To begin with, some good news!
I am so excited to announce that I have joined the 96Boards team at Linaro as an Applications Engineer 😀
As a part of my job I’d be responsible, along with my colleges for a lot of demo projects that are created by my team as well as a bunch of documentations and community support as usual.
This brings up an obvious question about the YouTube content, and the answer is pretty straight forward. Yes there would be a lot less videos, maybe one video per weekend with some exceptions now and then. I would still be reviewing other boards and non-96boards related content as well and promise to not let my position influence my reviews.
As for whats up next, today I will leave for San Francisco to attend Linaro Connect and hope to bring some great content and (V)(B)logs from the event, If you are visiting as well, hope to meet you at connect !
Welcome back everyone to another video, in this one we’ll be attempting to boot fuchsia os, or at least a part of it on an actual x86 PC based hardware. Fuchsia OS is still very much experimental at this stage, so expect more failures than success…
Before we get started I would like to give a shout out to sebe, who has on many occasions helped with Fuchsia and Magenta related issues…
So let’s get to it, there are some prerequisites before we get started, make sure that your fuchsia source is updated and you have completed the build for x86-64 target from the “getting started” guide. Once that is done, insert the usb drive that you want t make bootable while in the working directory execute the usb gigaboot build script inside the scripts folder.
This script has three options, one of which allows you to either use a basic magenta kernel based os without most of the Fuchsia functionality, we’ll look into it later on. Upon execution of the script, it will start to compile a few source files and after that it will ask the usb drive that is to be used to boot the OS, type the device name while making sure that you adhere to all the warnings as all of the data on the selected device will be wiped clean.
Once that is done the script will continue to write files to the USB drive, after it has completed the process it will automatically unmount the drive.
Finally now we can boot from the drive.
Here how it went for me, I didn’t boot at all on my laptop that is running on a pentium 3805U CPU, next the gigaboot bootloader booted fine on the same laptop but with a celeron based processor but failed to boot fuchsia or even just the magenta kernel.
Finally I tried it on the UP board that is running atom x5-z8350, which didn’t boot the full fuchsia os but was able to run the command line shell with the magenta kernel just fine…
And once again, this os is very experimental and supports a very small amount of intel hd gpu’s to display the GUI. and I can’t guarantee success as much as I can guarantee failure, but it’s still a fun experiment to do and just test what all hardware in your home or work is compatible with running the Fuchsia OS !!!
With that, I hope you enjoyed the show, thanks for liking sharing and subscribing and i’ll see you all in the next one.