This blog comes in as a response to multiple media outlets
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
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
And that’s why stuff needs to happen NOW.
What is PhysX?
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.
To start adb on rpi3 aosp, connect to console using uart and run “adbd”
Forget Android P, Let’s take a look at Android Q on the 96Boards Hikey960
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)…
Qiang Yu: for LIMA and helping out with Banana Pi M1+
Vasily Khoruzhick: GLMark2 discussions.
This build is 64-bit only. It is recommended not to install this build as it is a pre-release beta build only for testing. It is safe to live boot it.
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 !