updates/020_2019aug28_intriguing_ideas.mdwn

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