Arm Community Blog

Every single thing released by Espressif is ground-breaking marvel. They are single-handedly moving the world, are a distinct Atlas upon the universe, lifting this Earth up.

We are starting to see a couple low-cost would-be wifi System-on-Chip contendors. Realtek's RTL8720DN[1]. MediaTek was nominally going to be playing here[2] but has made almost no impact. Some few rare folks try to bring wifi to the world. But for the most part, there are dozens & dozens & dozens of fantastic, amazing, incredible, stupendous, delightful little microcontrollers in the world. But nearly none that embed wireless connectivity in a useful, usable fashion.

It is so weird, that a strange, unloved bizarre architecture, Xtensa, happened to be the one architecture that some chip maker decided to add wifi to. But lordy & heavens, it has made all the difference. Espressif continues to build chips that do what no one elses chips do: connect.

This is a pretty dramatic post, my apologies. I keep hoping wifi will become a more normal thing. I keep hoping chips traditionally sold for cell phones will start to get more love in the hobbyist market. Mid 2017, the "96boards" platform seemed to show hope for just that. An example was the HiKey 960, with a Huawei Kirin 960 octa-core chip with onboard wifi[3]. But the intervening three and a half years since then and now have been bleak. Access to good interesting modern chips has not increased. Folks like Espressif have remained not just a fallback, but the…

I know some of the Enlightenment core guys, and of course some of them work for Samsung; I've brought it up to them and it's safe to say that this is not a priority business case for them. They are all great folks, but with Samsung driving the train, I think this is no longer exclusively a volunteer project or necessarily strictly a labor of love for everyone anymore.

That being said, it should work. I've successfully installed the dev kit from ARM-MALI support which provides Ubuntu + Mali T604 drivers on an SD card or USB (this was a herculean effort, despite the instructions in question being made specifically for the specific device I have).

I haven't repeated this experiment, but I'd like to try again. I'd feel the chances it would work would be higher on Arch, where software is kept more up-to-date than on the ancient kernel and OS that ARM documentation suggested (it's Ubuntu, but not the current release, or even the current LTS release.)

You probably already found this page[1] -- r6p0 seems to be newer than when I tried last, maybe you also saw this one[2] -- the best "from-scratch" resource I've found that results in a working graphics driver, but good luck getting a modern release of E20 to compile on that... perhaps it could be upgraded without breaking everything.

This thread[3] I haven't visited for a while, but that chronicles my journey pretty well, at least prior to the point where I was trying ALARM or Arch Linux for ARM.

The arch install guide[4] is…

Yes, ordered dither is easier in a shader than error diffusion, that's true, but error diffusion is definitely possible on a GPU. If you need it. Do you really need it?
Why not still use the GPU to accelerate whatever parts you can? Even if you dither on the CPU, doing your color filters on the GPU instead of in JS could make the difference between interactive and not.

I don't know what you're doing exactly, but when you do need dithering, it's usually the last thing you need to do before output, and it's usually less important that the dither is fast than most other operations you need in an image editor.

BTW, random order is lower quality, and error diffusion is better, only for for very low res color palettes. If your result is more than 256 colors, it's irrelevant, and for high quality dithering, e.g., 16 bits per channel colors to 8 bits per channel for print, random ordered dithering is superior.

https://community.arm.com/graphics/b/blog/posts/when-parallelism-gets-tricky-accelerating-floyd-steinberg-on-the-mali-gpu

http://www.cs.cmu.edu/~imisra/projects/dithering/HybridDithering.pdf

https://www.shadertoy.com/view/4dt3W7

That last one is ugly, but it's a great proof of concept here. You could get error diffusion in a shader using 2 passes. The first pass you render to texture, and the second pass, you can sample the texture however you want. Note how in this example, the error diffusion propagates backwards from what you would normally do in JS or C++, because…

> Systems programming in any language would benefit immensely from better hardware accelerated bounds checking.

[Mostly discussed deeper in the thread already but felt it was worth bringing up directly as a reply to this]

This is an active area of development though still plenty of work to do. The Cambridge University Computer Lab have been doing research in this area in the form of CHERI: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/ this gives you hardware capabilities which are effectively pointers with bounds given out by the OS. Want to access something? You need the appropriate capability to do so.

ARM announced MTE last year, which whilst far less capable than CHERI begins to give you something (though it's targeted for bug hunting effectively rather than providing any actual security/safety properties): https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/enhancing-memory-safety

ARM are also building a hardware CHERI implementation, Morello: https://developer.arm.com/architectures/cpu-architecture/a-profile/morello. There's already CHERI implementations running BSD on FPGAs, this will take it to the next level with real silicon using modern ARM processors (maybe you could run android on it for instance?).

I think Intel have been looking along similar lines but I'm far less in touch with what they're up to so I don't have links.

This is for Cortex A8, which was the chip in the Nexus One. I wrote the original version of sound synthesis directly in ARM assembler[1]. It was very highly optimized, I remember using a cycle counting app that flagged any dependency chain that would cause the processor to stall, and ultimately utilization was in the 90%+ range. Back in those days, processors were simple enough you could do this kind of optimization by hand. By the time of Cortex A15 (Nexus 10 etc), instruction issue was out-of-order and much harder to reason about.

The best current info I could find for the latency advice is [2]. Quoting, "Moving data from NEON to ARM registers is Cortex-A8 is expensive." Looking at [3] partially reveals the reason why: the NEON pipeline is entirely after the integer pipeline, so moves from integer to NEON are cheap, but the reverse direction is potentially a large pipeline stall. This is an unusual design decision that as far as I know is not true for any other CPUs. Edit: I found [4], which is a more authoritative source.

[1]: https://github.com/google/music-synthesizer-for-android/blob/master/app/src/main/jni/neon_fm_kernel.s

[2]: https://community.arm.com/support-forums/f/armds-forum/757/neon-instruction-timing-latency

[3]: https://www.design-reuse.com/articles/11580/architecture-and-implementation-of-the-arm-cortex-a8-microprocessor.html

[4]:…

ARMv8.3-A added the new instruction LDAPR to allow acq_rel to be cheaper than seq_cst, so presumably it was worth adding.

This summarises (https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/armv8-a-architecture-2016-additions):

"The Armv8.0 support for release consistency is based around the “RCsc” (Release Consistency sequentially consistent) model described by Adve & Gharacholoo in [1], where the Acquire/Release instructions follow a sequentially consistent order with respect to each other. This is well aligned to the requirements of the C++11/C11 memory_order_seq_cst, which is the default ordering of atomics in C++11/C11."

"Instructions are added as part of Armv8.3-A to support the weaker RCpc (Release Consistent processor consistent) model where it is permissible that a Store-Release followed by a Load-Acquire to a different address can be re-ordered. This model is supported by the use of memory_order_release/ memory_order_acquire /memory_order_acqrel in C++11/C11."