Novena Update
bunniestudios.com
bunniestudios.com
Also see:
Wikipedia: Novena (computing platform)
https://en.wikipedia.org/wiki/Novena_(computing_platform)
Wikipedia: Andrew Huang
https://en.wikipedia.org/wiki/Andrew_Huang
Wired: The Almost Completely Open Source Laptop Goes on Sale
http://www.wired.com/2014/04/novena/
Laptop Magazine: Novena Helps Hackers Build Their Own Laptop
http://blog.laptopmag.com/novena-open-source-laptop
Crowd Supply: Novena Open Laptop
https://www.crowdsupply.com/kosagi/novena-open-laptop)
Crowd Supply: Novena Open Laptop Stretch Goals
https://www.crowdsupply.com/kosagi/novena-open-laptop/stretc...
Note: I have no connection with Bunnie Huang or Novena other than as a fellow engineer and interested potential customer.
Of course, I understand: doing hardware is hard, and there is an acute shortage of open source ARM SoC's. Still, I wish they could figure out a way to provide more hardware for a smaller price. If nothing else, it would help the adoption of an open hardware laptop greatly: it's kinda weird that all this work is so that only some 1,000 people would get their laptops.
I know the variety of hardware; started with ZX Spectrum (3.5 MHz 8-bit Z80), programmed TCP stack on a 25 MHz 16-bit CPU and I could be fine with a six-year-old laptop (typing on one, actually). Still, premium-priced laptop could use more power; especially if it's ARM, there's never too much.
Novena's 64 bit memory interface might actually make a big difference. From my tests, a 1080p 32 bit framebuffer uses up around 1/4 of the system memory bandwidth with a 32 bit DDR3 interface.
I also get the feeling that desktop browsers (chromium, firefox) aren't very well optimised for ARM.
Freescale provides hardware video decoding support for Chromium's GPU media stack[1].
chrome://gpu snippet on my Sabre Lite running Chromium 37.0.2062.120:
Graphics Feature Status
* Canvas: Software only. Hardware acceleration disabled
* Flash: Hardware accelerated
* Flash Stage3D: Hardware accelerated
* Flash Stage3D Baseline profile: Hardware accelerated
* Compositing: Hardware accelerated and threaded
* Rasterization: Hardware accelerated
* Threaded Rasterization: Enabled
* Video Decode: Hardware accelerated
* Video Encode: Hardware accelerated
* WebGL: Hardware accelerated
I'm mostly working on software for ARM and since all the tools I need for work run well enough, why not? I still use x86 at home.
> which ARM machines have you been using as desktop replacements?
The ones I've used most were IMX53QSB, then ODROID-X2, ODROID-XU and I'm now switching to ODROID-XU3.
> What advantages do they have over x86 machines?
I was able to get rid of the x86 desktop while only using ARM hardware I would have used anyway. Also, the boards have a tiny footprint (you can tape several to the back of a monitor for example), they're very low power and can be passively cooled. They're very cheap too.
I've also used some RK3188-based mini PCs dongles for their portability. You can carry a reasonably fast GNU/Linux machine in your pocket and don't cost much more than Raspberry Pi, which I find way too slow.
It's a hacker toy/tool.
For many tasks, from games to databases, FPGA's could provide huge benefits. The only reason I can see why FPGA's weren't adopted by mainstream PCs is that improving CPU's was so much easier. But with the ever-diminishing returns from x86 improvement, I can very well imagine that FPGAs could become viable in the mainstream.
FPGAs are generally good for accelerating data-parallel applications, but we already have had SIMD and GPGPU for a while. Both these technologies are only used by a small subset of the applications which could benefit from employing them. Why? I would say poor tools and abysmal programmer literacy. Automatic vectorization for SIMD sort of works, but it tends to miss lots of opportunities. Automatic acceleration with GPGPU is pretty much in the research phase. Manual development for SIMD and GPGPU takes skills that most developers don't seem to have at the moment and the trend towards high level, highly abstracted imperative languages isn't helping.
I guess at this point it might seem like I'm contradicting myself. The software side of things is lagging behind for GPGPU and SIMD, but these technologies are still mainstream. Why wouldn't the same happen for FPGA accelerators? My answer is cost. SIMD requires just a few small functional units and registers, a fairly small chip area in the processor compared to caches; the general purpose processor is itself a fairly small part of a SoC. GPGPU didn't require significant architectural changes from the shader model. FPGAs large enough to be useful, on the other hand, are expensive. Maybe economies of scale might make a smaller FPGA cheap enough to be included as an accelerator, but as far as I understand high transistor count / large area / low yield is unavoidable.
Plenty of exciting stuff going in research, but automatic use of accelerators would work much better by moving to a dataflow model of programming.
Personal prediction: non-monotonic same-ISA heterogeneous computing is going to be the next big thing, maybe in the form of reconfigurable pipelines. A bit more far fetched: phase-change materials for very aggressive short-term DVFS to lower latency on mobile.
Disclaimer: if I were a successful engineer, I would most certainly get one of these purely for the coolness factor.
The CPU & graphics are almost more of a programmer convenience than a fundamental selling point. You've got to have them, but they're there to control other things and do some basic number crunching.
"Interestingly enough, someone in the audience also asked about the price point. Cross replied that the comments break down into two distinct camps: FOSS people say "wow that's an expensive laptop" but FPGA users say "wow that's so cheap for a development kit!"