1 Pixilica starts a 3D Open Graphics Alliance initiative; we decide to
2 go with a "reconfigurable" pipeline; seven additional 50,000 EUR NLNet
3 grant proposals submitted.
5 ### The Possibility of a 3D Open Graphics Alliance
9 At SIGGRAPH this year, there was a very interesting BoF, where the
10 [idea was put forward](https://www.pixilica.com/forum/event/risc-v-graphical-isa-at-siggraph-2019/p-1/dl-5d62b6282dc27100170a4a05)
11 by Atif, of Pixilica, to use RISC-V as the core basis of a 3D embedded
12 flexible GPGPU (hybrid / general purpose GPU). Whilst the idea of a
13 GPGPU has been floated before (in particular by ICubeCorp), the
14 reasons *why* were what particularly caught people's attention at the
17 The current 3D GPU designs - NVIDIA, AMD, Intel - are hugely optimised
18 for mass volume appeal. Niche markets, by virtue of the profit
19 opportunities being lower or even negative given the design choices of
20 the incumbents, are inherently penalised. Not only that: whilst
21 things are slowly changing due to ongoing multi-man-year
22 reverse-engineering efforts, 3D driver source code is often
25 At the BoF, one attendee described how they are implementing
26 *transparent* shader algorithms. Most shader hardware provides
27 triangle algorithms that asume a solid surface. Using such hardware
28 for transparent shaders is a two-pass process which clearly comes with
29 an inherent *100%* performance penalty. If, on the other hand, they had
30 some input into a new 3D core, one that was designed to be flexible...
32 The level of interest was sufficiently high that Atif is reaching out
33 to people (including our team) to set up an Open 3D Graphics
34 Alliance. The basic idea being to have people work together to create
35 an appropriate efficient "Hybrid CPU/GPU" instruction set architecture
36 (ISA) suitable for a diverse range of requirements, from small
37 embedded softcores, to embedded GPUs for use in mobile processors, all
38 the way to HPC servers to high-end machine learning and robotics
41 One interesting thing that has to be made clear - the lesson from
42 Nyuzi and Larrabee - is that a good vector processor does **not**
43 automatically make a good 3D GPU. Jeff Bush designed Nyuzi very
44 specifically to replicate the Larrabee team's work - in particular, their
45 use of a recursive software-based tiling algorithm. By deliberately
46 not including custom 3D hardware accelerated opcodes, Nyuzi has only
47 25% the performance of a modern GPU consuming the same amount of power.
48 Put another way, if you want to use a pure vector engine to get the same
49 performance as a commercially competitive GPU, you need *four times*
50 the power consumption and four times the silicon area.
52 Thus, we simply cannot use an off-the-shelf vector extension such as the
53 upcoming RISC-V vector extension, or even SimpleV, and expect to
54 automatically have a commercially competitive 3D GPU. It takes texture
55 opcodes, Z-buffers, pixel conversion, linear interpolation, trascendentals
56 (sin, cos, exp, log), and much more, all of which has to be designed,
57 thought through, implemented, *and then used behind a suitable API*.
59 In addition, given that the Alliance is to meet the needs of "unusual"
60 markets, it is no good creating an ISA that has such a high barrier to
61 entry and such a power-performance penalty that it inherently excludes
62 the very implementors it is targetted at, particularly in embedded markets.
64 Thus, we need a hybrid architecture, not just to reduce complexity, not
65 just to meet Libre criteria, but to meet the long tail of innovation in
66 3D and kick start some real innovation.
68 These were the challenges discussed at the first
69 [meetup](https://www.meetup.com/Bay-Area-RISC-V-Meetup/events/264231095/)
70 at Western Digital's Milpitas HQ. Experts at the meetup from the 3D
71 industry who have worked for decades for ATI, NVIDIA, and Intel, were
72 really enthusiastic and praised this approach, saying that it was exactly
73 the kind of shake up the 3D Industry needs.
75 ### Reconfigureable Pipelines
77 Jacob came up with a fascinating idea: a reconfigureable pipeline. The
78 basic idea behind pipelines is that combinatorial blocks are separated
79 by latches. The reason is because when gates are chained together,
80 there is a ripple effect which has to have time to stabilise. If the
81 clock is run too fast, computations no longer have time to become valid.
83 So the solution is to split the combinatorial blocks into shorter chains,
84 and have "latches" in between them which capture the intermediary
85 results. This is termed a "pipeline." Actually it's more like an
88 The problem comes when you want to vary the clock speed. This is desirable
89 because if the pipeline is long and the clock rate is slow, clearly the latency
90 (completion time of an instruction) is also long.
92 Conversely, if the pipeline is short (large numbers of gates connected
93 together) then as mentioned above, this can inherently limit the maximum
94 frequency that the processor could run at, because, due to the "ripple" effect
95 in each pipeline stage, a longer chain of gates clearly has to have a longer
98 What if there was a solution which allowed *both* options? What if you
99 could actually reconfigure the pipeline to be shorter or longer?
101 It turns out that by using what is termed "transparent latches," it
102 is possible to do precisely that. The advantages are enormous and were
103 described in detail on comp.arch.
106 [this thread](https://groups.google.com/d/msg/comp.arch/fcq-GLQqvas/SY2F9Hd8AQAJ),
107 someone kindly pointed out that IBM published
108 papers on the technique. Basically, the latches normally present in the
109 pipeline have an additional combinatorial "bypass" in the form of a
110 mux. The output is dynamically selected from either the input *or* the
111 input after it has been put through a flip-flop. The flip-flop basically
112 stores (and delays) its input for one clock cycle, or it can be bypassed,
113 i.e., just be another part of that "ripple" effect mentioned earlier.
115 By putting these transparent latches on every other combinatorial stage
116 in the processing chain, the length of the pipeline may be halved, such
117 that when the clock rate is also halved the *instruction completion time
120 As described earlier, normally if the processor speed were lowered it
121 would have an adverse impact on instruction latency. With the transparent
122 latches bypassed and with plenty of time to stabilise at the lower speed,
123 two back-to-back stages now comprise a *single* pipeline stage, and thus,
124 even if the processor speed is halved,
125 *so is the length of the overall pipeline* and thus the instruction
126 completion time remains the same.
128 It's a fantastic idea that will allow us to reconfigure the processor
129 either to reach a 1.5 GHz clock rate for high performance bursts, or to
130 run at 800 MHz in reduced-power mode.
132 ### NLNet Funding Proposals
134 The next step is to put in over half a dozen NLNet funding proposals. No,
136 [seven new proposals](https://libre-riscv.org/nlnet_proposals/),
137 each for 50,000 EUR. One for gcc, one for a port of MESA RADV to the
138 new processor, another for writing experimental assembly code to go into
139 libswscale, libx264 etc. ultimately for use in VLC and ffmpeg, and so on.
141 Best of all, two for actually doing a test ASIC: one working with
142 [chips4makers](http://chips4makers.io/blog), the other with
143 [lip6.fr](https://www-soc.lip6.fr/en/). It turns out that 180 nm ASIC shuttle
144 services cost only 600 USD per square mm, and we can get away with around
145 20 square mm which is about 12,000 USD and an estimated 800,000 gates.
147 At that low cost, we can iterate before going to lower geometries plus
148 actually have something which, even at 350 MHz, if it was dual issue,
149 would be a reasonably saleable product in its own right. The only thing
150 we have to watch out for there, is that it will be a bit of a monster,
151 so power consumption is going to be high at 350 MHz. Still, for our first
152 ASIC ever, it's just exciting to think that it's possible at all.
154 Regarding the NLNet proposals: we need people! In particular, we need two
155 EU citizens to come forward, to satisfy NLNet's backers' requirements
156 (thanks to [NGU.eu](https://ngi.eu), NLNet has received its money under
157 the EU Horizon 2020 Programme), so at least one EU Citizen has to be
158 part of the proposal. One for gcc, another for the MESA/RADV port.
159 Please do contact me for details. There's no contract or obligation,
160 because this is charitable donations.
162 In addition, if anyone wants to receive tax deductible charitable
163 donations direct from NLNet for working on aspects of this project,
164 do get in touch, there is plenty to do. Application reviews start in two
165 weeks, we will hear from NLnet by December as to what has been approved,
166 and will be able to expand the project scope around January 2020.
168 Also, remember, if you work for a corporation that could financially
169 benefit from this project being a reality, sponsorship, via NLNet,
170 is tax deductible because it is a charitable donation.
172 (Update: covered in a
173 [Slashdot](https://hardware.slashdot.org/story/19/09/29/1845252/libre-risc-v-3d-cpugpu-seeks-grants-for-ambitious-expansion#comments)
projects / crowdsupply.git / blob