--- /dev/null
+Many thanks to Michael Larabel as he has been writing early articles
+on this project before we had a chance to get this pre-launch stage
+up and running, he picked up on the first update
+[here](http://www.phoronix.com/scan.php?page=news_item&px=Quad-Core-Libre-SoC-Proposal). The first article covered a lot more of the
+[technical details](https://www.phoronix.com/scan.php?page=news_item&px=Libre-GPU-RISC-V-Vulkan), and the second covered an announcement of
+[Kazan](https://www.phoronix.com/scan.php?page=news_item&px=Kazan-Vulkan-Rust),
+which implements the Vulkan 3D API.
+
+There has been quite a lot going on, including an enormous amount of
+planning for nearly six to eight months going on, so there are quite
+a few catch-up updates to write. It's worthwhile doing one that incorporates
+responses to Michael and to some of the people who also kindly asked
+questions and made comments on the
+[Phoronix Forum](https://www.phoronix.com/forums/node/1064199).
+
+I have no illusions about the cost of development of this project: it's
+going to be somewhere north of USD $6 million, with contingency of up
+to USD $10 million. This is just how it is. What that means is,
+interestingly, it means that there's provision for both investment and
+also to attract really, really good talent, and to properly pay for it.
+Where the project has started from is what can be achieved with the
+current resources. I've been kindly sponsored with a ZC706 FPGA board
+(worth over USD $2,500), which will allow one major hurdle to be cleared
+that will meet the criteria of many investors: making sure that the
+design is FPGA proven.
+
+Secondly, Michael, I note some incredulity at the goal of meeting the
+target of mobile-class 3D performance. It's actually extremely modest:
+100 million pixels per second, 30 million triangles per second, and around
+5 to 6 GFLOPs. These statistics were taken from the benchmarks for
+Vivante's GC800. Achieving these kinds of numbers is dead easy. Achieving
+them within a power envelope of under 2.5 watts? Not so easy!
+
+So here, what I did was, spend a considerable amount of time speaking to
+Jeff Bush, who developed
+[Nyuzi](https://www.phoronix.com/scan.php?page=news_item&px=LGPL-GPGPU-NyuziProcessor).
+Jeff's work is fascinating and extremely valuable because despite it being
+such low 3D peformance, the technical documentation and academic analysis
+of *why* that performance is so low is absolutely, absolutely critical.
+The [paper](http://www.cs.binghamton.edu/~millerti/nyuziraster.pdf) that
+Jeff co-authored makes a comparison of software and hardware rasterisation,
+and he actually developed a fixed-function hardware renderer called
+[ChiselGPU](https://github.com/jbush001/ChiselGPU) in order to do
+comparisons.
+
+One fascinating insight that came out of Jeff's work was that just getting
+data through the L1/L2 cache has a massive impact on power consumption.
+A way to deal with that is to increase the number of registers in the
+design until such time as the data being processed (a tile for example,
+or an inter-dependent 4-wide bank of 4x3 Floating-point numbers) can
+all fit into the register file, so as not to need to be pushed back down
+to the L1 cache and back. Some GPUs have a "scratch RAM" area to deal
+with this. Staggeringly, even for (or, especially for) a mobile-class
+GPU, we had to increase the register file size to a whopping 128 64-bit
+entries, that can be broken down into **256** 32-bit single-precision
+floating-point entries! What are we *doing*! This is supposed to be
+a modest design!
+
+A little digging around the Internet reveals that even mobile-class GPUs
+genuinely have this number of registers. More than that, though, it
+turns out that we may have a hidden advantage through implementing
+Kazan as a Vulkan Driver. In this
+[discussion](http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2018-October/000065.html)
+which follows on from a proposal on the LLVM mailing list about making
+Matrices a first-class type, Jacob informed me that the Vulkan API also
+passes in large batches of data that contains Matrices, and also arrays of
+data structures that need to be processed together. The problem here
+is that you want the elements of the arrays (or the Matrix) to be
+processed as if they were linear, preferably without having to move
+them around. Matrix multiplication for example typically requires the
+2nd matrix to be transposed (X swapped with Y) in order to access the
+elements in a linear fashion. What we decided to do instead was to
+add [1D/2D/3D data shaping](http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2018-October/000087.html). The elements *stay in-place* in the
+original registers, however a "remapper" engine makes them appear,
+as far as the parallel (SIMD/Vector) engine is concerned, as if the
+registers are contiguous. Register numbers 0 1 2 3 / 4 5 6 7 / 8 9 10 11
+get "remapped" to 0 4 8 / 1 5 9 / 2 6 10 / 3 7 11 without the need
+for "MV" instructions. Thanks to Mitch Alsup, the designer of the
+66000 ISA, we learned that this re-invented wheel has
+[also been implemented](https://groups.google.com/d/msg/comp.arch/bGBeaNjAKvc/_vbqyxTUAQAJ)
+in production GPUs and Vectorisation Systems.
+
+The point is that by picking Vulkan, and implementing both the hardware
+design and the software at the same time, we are both constrained
+*and guided* towards a successful design. In addition, as we know from
+previous successful (truly) open projects, the very fact that you are
+at liberty to talk about what you're doing (as compared to a secretive
+proprietary company) means that people with specialist expertise are
+more than happy to come forward and comment, and help guide you away
+from areas that have caught out billion-dollar companies in the past.
+
+The project thus becomes a *synthesis of the expertise and efforts
+of much more than just the people who are implementing it*.
+
+Just having the opportunity to do that is extremely humbling. Mitch Alsup,
+the designer of the famous Motorola 68000 series of processors,
+is giving us some feedback and input! Like... wow! For example,
+he made an extremely valuable recommendation
+[here](https://libre-riscv.org/3d_gpu/microarchitecture/) on how
+to save on register file space, only needing 1R1W (1x read-port,
+1x write-port) SRAM, by stretching out the pipeline phases to
+load operands sequentially rather than in parallel. I cannot express
+how grateful I am for his input, and for all the other people who
+have helped.
+
+So I believe we're in good hands, here. Ultimately, what is being
+presented here is more of an opportunity for anyone who has wanted
+something like this to succeed (or even exist), empowering them to
+go from "I wish someone would do this" to "I can help make it happen".
+This is one of the reasons why, if i am honest, I get slightly aggravated
+by people who write, "oh this project could not possibly succeed"
+or "this person could not possibly achieve this goal" as such comments
+entirely miss the point.
+
+As this update is quite long, I'll answer more on the Phoronix
+[comments](https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1064199-the-eoma68-libre-computer-developer-wants-to-tackle-a-quad-core-risc-v-libre-soc-design)
+however I particularly wanted to address one comment, here:
+*"This religious war target seems to be way off based on skill-set."*.
+As you can see above, I believe that one aspect of that comment has
+been addressed, above: as it's a libre project, unlike a proprietary
+company we're at liberty to get out on the Internet and ask peoples'
+advice before committing even to a design.
+
+The second aspect is the very silly "Religious War" implication. It's
+absolutely nothing of the kind. What many people do not know about me
+is that I pick projects that nobody else is doing, very very deliberately.
+I pick projects that make an ethical difference. That, if successful,
+many peoples' lives would be much better, less painful. It has absolutely
+sod-all to do with "Religious frothing fervour" (foam, foam).
+
+Many companies choose to make ethical compromises in order to make a profit.
+People are finally beginning to wake up to the consequences of this kind
+of concentration of financial and informational power. In India,
+people have been *murdered* based on Whatsapp viral hear-say. In the USA,
+democratic elections have been interfered with (Cambridge Analytica).
+I could very easily go to any of these massively-unethical Corporations,
+and make an absolute fortune in the process of empowering them to do a
+hundred more Cambridge Analyticas. *I choose not to do so*.
+
+So there are plenty of companies that make decisions without
+a moral compass, because, financially, it is easier to do so. And, more
+poignantly, it is legally permissible and *actively encouraged* by
+legal frameworks, tax incentives and Government-sanction monopolies
+known by the name "patents".
+
+What I am doing here is to demonstrate that none of that is necessary.
+That it is possible to design - and get funding for - a desirable
+product that happens also to be ethical. This is why the goal is
+as it is: a mobile-class processor, because that's the kind of product
+that could sell in large volumes at around the USD $4 mark.
+You won't see any Corporation taking on such a goal, as they're required
+to prioritise profits over ethics. So it's down to you,
+if you want this project to succeed, to help make it happen.
+
projects / crowdsupply.git / commitdiff