nlnet_2019_amdvlk_port.mdwn

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