nlnet_2019_amdvlk_port.mdwn

   1 # NL.net proposal
   2
   3 ## Project name
   4
   5 Port of AMDVLK 3D Driver to the Libre RISC-V SoC
   6
   7 ## Website / wiki
   8
   9 <https://libre-riscv.org/nlnet_2019_amdvlk_port>
  10
  11 Please be short and to the point in your answers; focus primarily on
  12 the what and how, not so much on the why. Add longer descriptions as
  13 attachments (see below). If English isn't your first language, don't
  14 worry - our reviewers don't care about spelling errors, only about
  15 great ideas. We apologise for the inconvenience of having to submit in
  16 English. On the up side, you can be as technical as you need to be (but
  17 you don't have to). Do stay concrete. Use plain text in your reply only,
  18 if you need any HTML to make your point please include this as attachment.
  19
  20 ## Abstract: Can you explain the whole project and its expected outcome(s).
  21
  22 The Libre RISCV SoC is being developed to provide a privacy-respecting
  23 modern processor, developed transparently and as libre to the bedrock
  24 as possible.  As a hybrid processor, it is intended to be both a CPU
  25 *and* a GPU.  GPUs are normally proprietary (and thus are perfect candidate
  26 attack vectors), as is the 3D driver software.
  27
  28 In January 2019, AMD released a fully-functioning libre-licensed Vulkan
  29 Driver for their Radeon GPUs.  A close examination of its source code
  30 shows that it would be relatively straightforward to replace the libraries
  31 that generate Radeon GPU assembly code with ones that generate assembly
  32 for the Libre RISC-V SoC, instead.
  33
  34 Thus we intend to do exactly that: leverage AMD's excellent work to create
  35 a libre-licensed commercial-grade Vulkan 3D driver that takes full advantage
  36 of the parallelism and Vectorisation in the hybrid Libre RISC-V SoC.
  37
  38 # Have you been involved with projects or organisations relevant to this project before? And if so, can you tell us a bit about your contributions?
  39
  40 Luke Leighton is an ethical technology specialist who has a consistent
  41 24-year track record of developing code in a real-time transparent
  42 (fully libre) fashion, and in managing Software Libre teams.  He is the
  43 lead developer on the Libre RISC-V SoC.
  44
  45 Jacob Lifshay is a software libre 3D expert who developed a Vulkan 3D
  46 software render engine under the GSoc2017 Programme.  He also developed
  47 his own libre-licensed 32-bit RISC-V processor, and has written an
  48 optimising javascript compiler.  Jacob is a valuable member of the team and is
  49 working on Kazan (https://salsa.debian.org/Kazan-team/kazan)
  50
  51 # Requested Amount
  52
  53 EUR 50,000.
  54
  55 # Explain what the requested budget will be used for?
  56
  57 We are aiming for a multi-stage process, starting with the basics:
  58
  59 * The first stage is to remove AMD's "PAL" Library and replace it with
  60   a straightforward upstream port of the current LLVM JIT compiler,
  61   alongside a "support" library that will call OpenCL / OpenGL
  62   functions directly on the main processor.  This "effectively"
  63   turns AMDVLK into a peer of google swiftshader (a "Software 3D Renderer").
  64 * The second stage is to confirm that the standard RISC-V LLVM JIT
  65   (which was recently upstreamed as of LLVM 9.0.0) is properly functional
  66   under an emulator or other RV64GC system.
  67 * The third phase will be to begin the iterative process, tying in closely
  68   with the work on Kazan, to experiment in both a software simulator
  69   as well as in FPGAs, with the addition of both Vectorisation as well
  70   as custom opcodes that will significantly improve performance as well
  71   as meet commercially-acceptable power-performance demands.
  72
  73 At the point where commercial power-performance requirements are met we may
  74 officially declare the project a "success".
  75
  76 # Does the project have other funding sources, both past and present?
  77
  78 The overall project has sponsorship from Purism as well as a prior grant
  79 from NLNet.  However that is for specifically covering the development
  80 of the RTL (the hardware source code), and for a "parallel" 3D Vulkan
  81 Driver effort, Kazan.
  82
  83 Kazan is to be written in Rust and its inclusion in the initial 2018
  84 proposal was *before* AMDVLK was released (Jan 2019).  AMDVLK is written
  85 in c++, is a significant way along (further than Kazan), however there
  86 is a different design focus in each that makes choosing one over the
  87 other not only difficult but potentially a costly mistake.
  88
  89 # Compare your own project with existing or historical efforts.
  90
  91 Nyuzi is a Software-based 3D Engine that has an LLVM port.  The problem
  92 is that it has deliberately been designed to be a software-only Vector
  93 Processor.  As such, with no custom accelerated opcodes dedicated to 3D,
  94 its power-performance metric is a whopping 25% that of commercially-acceptable
  95 3D GPUs.  It also has no actual 3D Vulkan Driver: the developers focussed
  96 only on the "core algorithms".
  97
  98 Google's swiftshader is a software-based 3D Driver/Engine that is compatible
  99 with at least one version of Vulkan.  On the face of it, this would be a
 100 perfect match for the Libre RISC-V SoC due to it being a hybrid CPU / GPU.
 101 The problem is that swiftshader was designed - from the ground up - never
 102 to have Vectorisation or any form of accelerated hardware beyond SIMD
 103 (NEON, Altivec, SSE/AVX).  As Nyuzi clearly shows, this approach is
 104 known to give a massive 400% power penalty.  Not only that, but our
 105 additions would not be welcome due to the primary focus of swiftshader
 106 being on non-hardware-accelerated, non-custom processors.
 107
 108 Our initial proposal - Kazan - is much more interesting to discern and
 109 compare against.  Kazan is being specifically designed so that the
 110 SPIR-V compiler is capable of fully supporting "full-function vectorisation".
 111 LLVM IR does *NOT* normally support this (which is why SPIR-V was created
 112 by the Khronos Group in the first place).  However, AMDVLK, which is a
 113 hard fork of LLVM, has had its LLVM-IR specifically modified to support
 114 both full-function vectorisation, predication, and in addition, texturisation,
 115 such that this information may be "carried" down to the Radeon assembly level,
 116 through the PAL library.
 117
 118 Standard LLVM does *not* support this full-function vectorisation
 119 capability: it is typically left up to any given assembly-level
 120 converter (such as the RISC-V Vector Engine) to "opportunistically"
 121 turn non-vectorised programs *into* vectorised ones, whereas AMDVLK
 122 *explicitly* carries this very same information.
 123
 124 Kazan on the other hand intends to perform explicit Vectorisation
 125 code-transformations in a different location: inside the SPIR-V compiler
 126 itself.  This key radical technical difference is why we seek to explore
 127 the alternative approach taken by AMD side-by-side with that of Kazan,
 128 because it is just not possible to predict in advance which would be "better".
 129
 130 ## What are significant technical challenges you expect to solve during the project, if any?
 131
 132 This is compiler technology, which is traditionally viewed as particularly
 133 challenging.  We are slightly fortunate in that much of the pieces of the
 134 puzzle already exist: AMDVLK, the upstreamed acceptance of RISC-V LLVM 9.0.0
 135 being the key ones.
 136
 137 Whilst we know *technically* what they did and why they did it, the key
 138 challenge will be to unravel what exact changes AMD made which caused
 139 them to have to "fork" LLVM several years back, to keep track of their
 140 efforts to introduce "mainline" LLVM patches on an ongoing piecemeal
 141 basis, and at the same time *add our own assembler back-end* into the
 142 same fast-moving target.
 143
 144 ## Describe the ecosystem of the project, and how you will engage with relevant actors and promote the outcomes?
 145
 146 As mentioned in the 2018 submission, the Libre RISC-V
 147 SoC has a full set of resources for Libre Project Management and development:
 148 mailing list, bugtracker, git repository and wiki - all listed here:
 149 <https://libre-riscv.org/>
 150
 151 In addition, we have a Crowdsupply page
 152 <https://www.crowdsupply.com/libre-risc-v/m-class> which provides a public
 153 gateway, and heise.de, reddit, phoronix, slashdot and other locations have
 154 all picked up the story.  The list is updated and maintained here:
 155 <https://libre-riscv.org/3d_gpu/>
 156
 157 # Extra info to be submitted
 158
 159 * <http://libre-riscv.org/3d_gpu/>
 160 * <https://nlnet.nl/project/Libre-RISCV/>
 161 * <https://github.com/GPUOpen-Drivers/AMDVLK>
 162 * <https://github.com/google/swiftshader/>
 163 * <https://salsa.debian.org/Kazan-team/kazan>