-Intriguing Ideas
+Pixilica starts a 3D Open Graphics Alliance initiative; we decide to
+go with a "reconfigurable" pipeline; seven additional 50,000 EUR NLNet
+grant proposals submitted.
-Pixilica starts a 3D Open Graphics Alliance initiative;
-We decide to go with a "reconfigurable" pipeline;
+### The Possibility of a 3D Open Graphics Alliance
-# The possibility of a 3D Open Graphics Alliance
+youtube: HeVz-z4D8os
-At SIGGRAPH 2019 this year there was a very interesting BoF, where the
+At SIGGRAPH this year, there was a very interesting BoF, where the
[idea was put forward]
(https://www.pixilica.com/forum/event/risc-v-graphical-isa-at-siggraph-2019/p-1/dl-5d62b6282dc27100170a4a05)
-by Atif, of Pixilica, to use RISC-V as the core
-basis of a 3D Embedded flexible GPGPU (hybrid / general purpose GPU).
-Whilst the idea of a GPGPU has been floated before (in particular by
-ICubeCorp), the reasons *why* were what particularly caught peoples'
-attention at the BoF.
+by Atif, of Pixilica, to use RISC-V as the core basis of a 3D embedded
+flexible GPGPU (hybrid / general purpose GPU). Whilst the idea of a
+GPGPU has been floated before (in particular by ICubeCorp), the
+reasons *why* were what particularly caught people's attention at the
+BoF.
-The current 3D GPU designs - NVIDIA, AMD, Intel, are hugely optimised
+The current 3D GPU designs - NVIDIA, AMD, Intel - are hugely optimised
for mass volume appeal. Niche markets, by virtue of the profit
opportunities being lower or even negative given the design choices of
-the incumbents, are inherently penalised. Not only that but the source
-code of the 3D engines is proprietary, meaning that anything outside of
-what is dictated by the incumbents is out of the question.
-
-At the BoF, one attendee described how they are implementing *transparent*
-shader algorithms. Most shader hardware provides triangle algorithms that
-asume a solid surface. Using such hardware for transparent shaders is a
-2 pass process which clearly comes with an inherent *100%* performance
-penalty. If on the other hand they had some input into a new 3D core,
-one that was designed to be flexible...
-
-The level of interest was sufficiently high that Atif is reaching out to
-people (including our team) to set up an Open 3D Graphics Alliance. The
-basic idea being to have people work together to create an appropriate
-efficient "Hybrid CPU/GPU" Instruction Set (ISA) suitable for a diverse
-range of architectures and requirements: all the way from small embedded
-softcores, to embedded GPUs for use in mobile processors, to HPC servers
-to high end Machine Learning and Robotics applications.
-
-One interesting thing that has to be made clear - the lesson from Nyuzi
-and Larrabee - is that a good Vector Processor does **not** automatically
-make a good 3D GPU. Jeff Bush designed Nyuzi very specifically to
-replicate the Larrabee team's work. By deliberately not including custom
-3D Hardware Accelerated Opcodes, Nyuzi has only 25% the performance of a modern
-GPU consuming the same amount of power. Put another way: if you want to use
-a pure Vector Engine to get the same performance as a commercially-competitive
-GPU, you need *four times* the power consumption and four times the silicon
-area.
-
-Thus we simply cannot use the upcoming RISC-V Vector Extension, or even
-SimpleV, and expect to automatically have a commercially competitive
-3D GPU. It takes texture opcodes, Z-Buffers, pixel conversion, Linear
-Interpolation, Trascendentals (sin, cos, exp, log), and much more, all
-of which has to be designed, thought through, implemented *and then used
-behind a suitable API*.
+the incumbents, are inherently penalised. Not only that: whilst
+things are slowly changing due to ongoing multi-man-year
+reverse-engineering efforts, 3D driver source code is often
+proprietary as well.
+
+At the BoF, one attendee described how they are implementing
+*transparent* shader algorithms. Most shader hardware provides
+triangle algorithms that asume a solid surface. Using such hardware
+for transparent shaders is a two-pass process which clearly comes with
+an inherent *100%* performance penalty. If, on the other hand, they had
+some input into a new 3D core, one that was designed to be flexible...
+
+The level of interest was sufficiently high that Atif is reaching out
+to people (including our team) to set up an Open 3D Graphics
+Alliance. The basic idea being to have people work together to create
+an appropriate efficient "Hybrid CPU/GPU" instruction set architecture
+(ISA) suitable for a diverse range of requirements, from small
+embedded softcores, to embedded GPUs for use in mobile processors, all
+the way to HPC servers to high-end machine learning and robotics
+applications.
+
+One interesting thing that has to be made clear - the lesson from
+Nyuzi and Larrabee - is that a good vector processor does **not**
+automatically make a good 3D GPU. Jeff Bush designed Nyuzi very
+specifically to replicate the Larrabee team's work - in particular, their
+use of a recursive software-based tiling algorithm. By deliberately
+not including custom 3D hardware accelerated opcodes, Nyuzi has only
+25% the performance of a modern GPU consuming the same amount of power.
+Put another way, if you want to use a pure vector engine to get the same
+performance as a commercially competitive GPU, you need *four times*
+the power consumption and four times the silicon area.
+
+Thus, we simply cannot use an off-the-shelf vector extension such as the
+upcoming RISC-V vector extension, or even SimpleV, and expect to
+automatically have a commercially competitive 3D GPU. It takes texture
+opcodes, Z-buffers, pixel conversion, linear interpolation, trascendentals
+(sin, cos, exp, log), and much more, all of which has to be designed,
+thought through, implemented, *and then used behind a suitable API*.
In addition, given that the Alliance is to meet the needs of "unusual"
markets, it is no good creating an ISA that has such a high barrier to
entry and such a power-performance penalty that it inherently excludes
-the very implementors it is targetted at, particularly in Embedded markets.
+the very implementors it is targetted at, particularly in embedded markets.
-https://youtu.be/HeVz-z4D8os
+Thus, we need a hybrid architecture, not just to reduce complexity, not
+just to meet Libre criteria, but to meet the long tail of innovation in
+3D and kick start some real innovation.
-# Reconfigureable Pipelines
+These were the challenges discussed at the first
+[meetup](https://www.meetup.com/Bay-Area-RISC-V-Meetup/events/264231095/)
+at Western Digital's Milpitas HQ. Experts at the meetup from the 3D
+industry who have worked for decades for ATI, NVIDIA, and Intel, were
+really enthusiastic and praised this approach, saying that it was exactly
+the kind of shake up the 3D Industry needs.
+
+### Reconfigureable Pipelines
Jacob came up with a fascinating idea: a reconfigureable pipeline. The
basic idea behind pipelines is that combinatorial blocks are separated
-by latches. The reason is because when gates are chained together,
+by latches. The reason is because when gates are chained together,
there is a ripple effect which has to have time to stabilise. If the
clock is run too fast, computations no longer have time to become valid.
So the solution is to split the combinatorial blocks into shorter chains,
and have "latches" in between them which capture the intermediary
-results. This is termed a "pipeline". Actually it's more like an
+results. This is termed a "pipeline." Actually it's more like an
escalator.
The problem comes when you want to vary the clock speed. This is desirable
-because if the pipeline is long and the clock rate is slow, the latency
+because if the pipeline is long and the clock rate is slow, clearly the latency
(completion time of an instruction) is also long.
Conversely, if the pipeline is short (large numbers of gates connected
together) then as mentioned above, this can inherently limit the maximum
-frequency that the processor could run at.
+frequency that the processor could run at, because, due to the "ripple" effect
+in each pipeline stage, a longer chain of gates clearly has to have a longer
+time to stabilise.
What if there was a solution which allowed *both* options? What if you
-could actually reconfigure tge pipeline to be shorter or longer?
-
-It turns out that by using what is termed "transparent latches" that it
-is possible to do precisely that. The advantages are enormous and were
-described in detail on comp.arch
-
-https://groups.google.com/d/msg/comp.arch/fcq-GLQqvas/SY2F9Hd8AQAJ
-Earlier in that thread, someone kindly pointed out that IBM published
-papers on the technique. Basically, the latches normally present in the
-pipeline have a combinatorial "bypass" in the form of a Mux. The output
-is dynamically selected from either the input *or* the input after it
-has been put through a flip-flop. The flip-flop basically stores (and
-delays) its input for one clock cycle.
+could actually reconfigure the pipeline to be shorter or longer?
+
+It turns out that by using what is termed "transparent latches," it
+is possible to do precisely that. The advantages are enormous and were
+described in detail on comp.arch.
+
+Earlier in
+[this thread](https://groups.google.com/d/msg/comp.arch/fcq-GLQqvas/SY2F9Hd8AQAJ),
+someone kindly pointed out that IBM published
+papers on the technique. Basically, the latches normally present in the
+pipeline have an additional combinatorial "bypass" in the form of a
+mux. The output is dynamically selected from either the input *or* the
+input after it has been put through a flip-flop. The flip-flop basically
+stores (and delays) its input for one clock cycle, or it can be bypassed,
+i.e., just be another part of that "ripple" effect mentioned earlier.
By putting these transparent latches on every other combinatorial stage
in the processing chain, the length of the pipeline may be halved, such
that when the clock rate is also halved the *instruction completion time
remains the same*.
-Normally if the processor speed were lowered it would have an adverse
-impact on instruction latency.
+As described earlier, normally if the processor speed were lowered it
+would have an adverse impact on instruction latency. With the transparent
+latches bypassed and with plenty of time to stabilise at the lower speed,
+two back-to-back stages now comprise a *single* pipeline stage, and thus,
+even if the processor speed is halved,
+*so is the length of the overall pipeline* and thus the instruction
+completion time remains the same.
It's a fantastic idea that will allow us to reconfigure the processor
-to reach a 1.5ghz clock rate for high performance bursts.
-
+either to reach a 1.5 GHz clock rate for high performance bursts, or to
+run at 800 MHz in reduced-power mode.
+
+### NLNet Funding Proposals
+
+The next step is to put in over half a dozen NLNet funding proposals. No,
+literally:
+[seven new proposals](https://libre-riscv.org/nlnet_proposals/),
+each for 50,000 EUR. One for gcc, one for a port of MESA RADV to the
+new processor, another for writing experimental assembly code to go into
+libswscale, libx264 etc. ultimately for use in VLC and ffmpeg, and so on.
+
+Best of all, two for actually doing a test ASIC: one working with
+[chips4makers](http://chips4makers.io/blog), the other with
+[lip6.fr](https://www-soc.lip6.fr/en/). It turns out that 180 nm ASIC shuttle
+services cost only 600 USD per square mm, and we can get away with around
+20 square mm which is about 12,000 USD and an estimated 800,000 gates.
+
+At that low cost, we can iterate before going to lower geometries plus
+actually have something which, even at 350 MHz, if it was dual issue,
+would be a reasonably saleable product in its own right. The only thing
+we have to watch out for there, is that it will be a bit of a monster,
+so power consumption is going to be high at 350 MHz. Still, for our first
+ASIC ever, it's just exciting to think that it's possible at all.
+
+Regarding the NLNet proposals: we need people! In particular, we need two
+EU citizens to come forward, to satisfy NLNet's backers' requirements
+(thanks to [NGU.eu](https://ngi.eu), NLNet has received its money under
+the EU Horizon 2020 Programme), so at least one EU Citizen has to be
+part of the proposal. One for gcc, another for the MESA/RADV port.
+Please do contact me for details. There's no contract or obligation,
+because this is charitable donations.
+
+In addition, if anyone wants to receive tax deductible charitable
+donations direct from NLNet for working on aspects of this project,
+do get in touch, there is plenty to do. Application reviews start in two
+weeks, we will hear from NLnet by December as to what has been approved,
+and will be able to expand the project scope around January 2020.
+
+Also, remember, if you work for a corporation that could financially
+benefit from this project being a reality, sponsorship, via NLNet,
+is tax deductible because it is a charitable donation.
+
+(Update: covered in a
+[Slashdot](https://hardware.slashdot.org/story/19/09/29/1845252/libre-risc-v-3d-cpugpu-seeks-grants-for-ambitious-expansion#comments)
+article)
projects / crowdsupply.git / blobdiff