This blog comes in as a response to multiple media outlets qutoting Linus Torvald’s announcement that x86 won over Arm… :sigh:

First of all, STFU with all the clickbait-y title BS.

Coming to the actual point, here is the forum post where Linus stated that x86 won.


The forum thread started with people discussing the newly released Arm Ares aka Neoverse N1 for the server space. In the thread, the first post by Linus(a reply to OP) he states, “We’ll see if it actually delivers, but ARM is certainly looking a whole lot better than it used to.”

To which ‘anon’ replies that “They (arm) have no market for an 8 core design. They would have to not just match but beat x86 in single threaded performance for there to be any reason to use such a thing.”
> The plot thickens

Then comes Linus’s much-hyped post where he argues that “performance” is not really the reason. The main reason is that Arm still heavily relies on cross-platform development. Whether its a server/cloud or mobile target, for the most part, the majority of the development is done on an x86 PC, cross-compiled and finally deployed on Arm.
He proceeds to state that the reason x86 is so successful is that developers have direct access to an x86 machine in their homes in the form of their desktops and workstation.

Now, I do agree with what he said in that thread, about having a Arm desktop to directly develop for Arm on Arm.
I just don’t really agree with his last statement “It’s why x86 won.”.

If there was ever a war between Arm and x86, and believe me we ARE at war. The Arm ecosystem is just getting started.
We already have desktop/laptop specific chipsets from the like of Qualcomm with the SD850 and SD8cx, and even some of the mobile chipsets like the Hisilicon Kirin970 and Qcom SD845/855 are more than capable of being used in a desktop scenario. We also have some of the more industrial chipsets with multiple A72 cores on a single chip.
So that’s performance sorted, we even have development boards from the likes of 96Boards with above mentioned SoCs.

So what is really missing then?
Two things specifically:
– A Desktop friendly form factor: Like a NUC.
– Standardization: Now since we are aiming for a developer platform, rather than a development platform. Stuff needs to “Just Work”. Generic Arm distro images need to “Just Boot”. No more board specific images, board-specific kernel, board-specific needs to stop being a thing. And this is something the community has been begging for ages.
SBBR and SBSA implementation need to happen, Tianocore and Linux kernel upstreaming efforts need to happen and stop being something “optional”. And I am literally just repeating the words of the Arm community, its time vendors step up big time.

As for me, I’ll be at Linaro Connect BKK19 talking about this exact Arm DUC along with a few more link-minded members of the Arm community. Our session is titled “BKK19-302 Designing a next generation ARM Developer Platform” where we aim to discuss what needs to happen to make “Arm Developer’s kit” a reality.

And that’s why stuff needs to happen NOW.

What is PhysX?

PhysX is an open-source[1] realtime physics engine middleware SDK developed by Nvidia as a part of Nvidia GameWorks software suite.

Video games supporting PhysX can be accelerated by either a PhysX PPU (expansion card designed by Ageia) or a CUDA-enabled GeForce GPU thus offloading physics calculations from the CPU, allowing it to perform other tasks instead.

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.

 

OpenSorced:

https://www.engadget.com/2018/12/03/nvidia-physx-open-source/

 

Github:

https://github.com/NVIDIAGameWorks/PhysX

 

Experiment 1) Discovering LIMA:

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)…

 

Acknowledgements:

Qiang Yu: for LIMA and helping out with Banana Pi M1+

Erico Nunes: For Allwinner LIMA Buildroot

Neil Armstrong: For Help with Kadas Vim and Amlogic OE meta layer and moon landing

Vasily Khoruzhick: GLMark2 discussions.

Hey all,

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 !

Mainpage: https://fuchsia.googlesource.com/docs/+/master/book.md

Getting started https://fuchsia.googlesource.com/docs/+/master/getting_started.md

 

Transcript:

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.