nlnet_2019_opencl.mdwn

   1 # NL.net proposal
   2
   3 ## Project name
   4
   5 OpenCL hardware support on Libre RISC-V
   6
   7 ## Website / wiki
   8
   9 <https://libre-riscv.org/nlnet_2019_opencl>
  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 RISC-V SoC is being developed to provide a privacy-respecting
  23 modern processor, developed transparently and as libre to the bedrock
  24 as possible.
  25
  26 As a hybrid processor, it is intended to be both a CPU
  27 *and* a GPU. GPUs are normally proprietary (and thus are perfect candidate
  28 attack vectors), as is the low-level software that runs on it.
  29
  30 Despite the original meaning of GPU, GPUs are not only limited to graphics
  31 processing. In fact, there is a quite common use case of using GPUs for
  32 more general computation these days. The work of scientists, AI and ML
  33 developers, multimedia applications such as FFmpeg, etc., depend on
  34 unique traits of GPUs to accelerate their processing. A standard, open API
  35 to facilitate this is OpenCL.
  36
  37 Almost all the major mobile-class GPUs, such as Vivante GC, ARM Mali,
  38 Broadcom VideoCore, and Qualcomm Adreno, support OpenCL, but of course
  39 they are proprietary implementations which cannot be trusted completely.
  40
  41 While the mobile-class GPUs have terrible open-source support, at least
  42 the bigger GPU names such as AMD and Intel have open-sourced their OpenCL
  43 solutions. In addition, since we are reusing the SPIR-V/LLVM/Mesa stack
  44 for Vulkan (as detailed in our AMDVLK/RADV NlNet proposal) and OpenGL
  45 support, Mesa also happens to come with an OpenCL implementation which
  46 we can possibly reuse as well (Gallium/Clover).
  47
  48 However, these OpenCL implementations tend to be very specific to the
  49 vendors processors so we will have to investigate which pieces to reuse
  50 and develop our own specific implementation. Furthermore, we cannot
  51 infinitely delay our first iteration of the Libre RISC-V SoC. Therefore,
  52 this proposal is limited to only doing the hardware requirements of
  53 OpenCL first. In a future proposal for the second iteration of
  54 Libre RISC-V, we will work on the software requirements of OpenCL.
  55
  56 Thus we intend to do exactly that: leverage the excellent work already
  57 done to create a libre-licensed commercial-grade OpenCL driver that
  58 takes full advantage of the parallelism and vectorisation in the
  59 hybrid Libre RISC-V SoC to accelerate compute applications.
  60
  61 # 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?
  62
  63 Luke Leighton is an ethical technology specialist who has a consistent
  64 24-year track record of developing code in a real-time transparent
  65 (fully libre) fashion, and in managing Software Libre teams.  He is the
  66 lead developer on the Libre RISC-V SoC.
  67
  68 Jacob Lifshay is a software libre 3D expert who developed a Vulkan 3D
  69 software render engine under the GSoc2017 Programme.  He also developed
  70 his own libre-licensed 32-bit RISC-V processor, and has written an
  71 optimising javascript compiler.  Jacob is a valuable member of the team and is
  72 working on Kazan (https://salsa.debian.org/Kazan-team/kazan)
  73
  74 # Requested Amount
  75
  76 EUR 50,000.
  77
  78 # Explain what the requested budget will be used for?
  79
  80 After a thorough and comprehensive evaluation to see which will be the
  81 best to choose (Intel NEO, AMD ROCm, Mesa Gallium/Clover), we are aiming
  82 for a multi-stage process, starting with the basics:
  83
  84 * The first stage is to make sure we have the necessary hardware
  85   support for hardware acceleration of OpenCL. OpenCL would be pointless
  86   if all done in software.
  87 * The second stage (in a future proposal) is to create a basic OpenCL
  88   driver by looking at how other OpenCL implementations are done.
  89 * The third phase (in a future proposal) will be to begin the iterative
  90   process, to experiment in both a software simulator as well as in FPGAs,
  91   with the addition of both vectorisation as well as custom opcodes that
  92   will significantly improve performance as well as meet
  93   commercially-acceptable power-performance demands.
  94
  95 At the point where commercial power-performance requirements are met and
  96 OpenCL applications are able to run on Libre RISC-V without software
  97 emulation, we may officially declare the project a "success".
  98
  99 # Does the project have other funding sources, both past and present?
 100
 101 The overall project has sponsorship from Purism as well as a prior
 102 grant from NLNet. However that is for specifically covering the
 103 development of the RTL (the hardware source code).
 104
 105 Actual development of OpenCL drivers, accelerated by the capabilities
 106 of this hybrid design, was not part of the original proposal.
 107
 108 A previous proposal supported the creation of Kazan which will serve
 109 as a Vulkan graphics driver. While Vulkan does have some compute
 110 capabilities, its use is limited to the graphics domain. This OpenCL
 111 driver will allow for full compute cabilities on Libre RISC-V.
 112
 113 # Compare your own project with existing or historical efforts.
 114
 115 The Vivante GC800 is capable of OpenCL but as many other mobile-class
 116 GPUs, it is proprietary.
 117
 118 The Broadcom VideoCore GPU used in Raspberry Pis are also capable of OpenCL.
 119 In the future, it is very likely that Libre RISC-V will be used to create
 120 a Single-board computer (SBC) just like a Raspberry Pi (possibly by us or
 121 third-party).
 122
 123 Intel's NEO is a modern OpenCL driver that leverages an LLVM-based graphics
 124 compiler stack to provide OpenCL usage for Intel GPUs. Compared to other
 125 OpenCL implementations, the community considers Intel's to be the best one
 126 and NEO also is compliant with the latest OpenCL standard at 2.2.
 127
 128 AMD's ROCm not only provides an OpenCL driver, but also AMD's own specific
 129 compute stack that deviates from OpenCL. ROCm supports an older version
 130 of OpenCL 2.0 but not higher.
 131
 132 Kazan is our Vulkan graphics driver. While Vulkan can be used for a limited
 133 set of compute functionality geared towards graphics use-cases, Vulkan is
 134 not meant to be used for general-purpose compute.
 135
 136 There are also some open-source projects (clvk, clspv) to adapt OpenCL on
 137 Vulkan, however, given that Vulkan is a completely different API than OpenCL,
 138 there will likely be drawbacks to this approach as well as a performance
 139 penalty for not having OpenCL support in hardware. Moreover, clvk and clspv
 140 only support OpenCL 1.2.
 141
 142 Nvidia has very limited OpenCL support due mainly to the fact that they have
 143 a competing compute solution called CUDA. As such, they are stuck on OpenCL 1.2
 144 in order to promote their own proprietary API instead. As a libre project,
 145 we cannot support a closed solution such as CUDA and instead we will support
 146 the alternative open Khronos standard for compute - OpenCL.
 147
 148 ## What are significant technical challenges you expect to solve during the project, if any?
 149
 150 There are many levels to supporting OpenCL. This proposal is only meant for
 151 funding the development of hardware acceleration for OpenCL which should be
 152 relatively easier to do given that Vulkan and OpenCL share some low-level
 153 details.
 154
 155 A future proposal will detail the software side which will require *far* more
 156 engineering resources because we will have to handle the runtime and compiler
 157 technology for the OpenCL driver.
 158
 159 ## Describe the ecosystem of the project, and how you will engage with relevant actors and promote the outcomes?
 160
 161 As mentioned in the 2018 submission, the Libre RISC-V
 162 SoC has a full set of resources for Libre Project Management and development:
 163 mailing list, bugtracker, git repository and wiki - all listed here:
 164 <https://libre-riscv.org/>
 165
 166 In addition, we have a Crowdsupply page
 167 <https://www.crowdsupply.com/libre-risc-v/m-class> which provides a public
 168 gateway, and heise.de, reddit, phoronix, slashdot and other locations have
 169 all picked up the story.  The list is updated and maintained here:
 170 <https://libre-riscv.org/3d_gpu/>
 171
 172 # Extra info to be submitted
 173
 174 Applications of OpenCL/GPGPU:
 175
 176 * <https://en.wikipedia.org/wiki/List_of_OpenCL_applications>
 177 * <https://en.wikipedia.org/wiki/General-purpose_computing_on_graphics_processing_units#Applications>
 178 * <https://wiki.archlinux.org/index.php/GPGPU>
 179
 180 Implementations:
 181
 182 * Intel Neo <https://01.org/compute-runtime>
 183 * AMD ROCm <https://rocm.github.io/>
 184 * Google clspv <https://github.com/google/clspv>
 185 * clvk <https://github.com/kpet/clvk>
 186 * Mesa OpenCL <https://gitlab.freedesktop.org/mesa/mesa/tree/master/include/CL>
 187 * <https://www.iwocl.org/resources/opencl-implementations/>
 188
 189 Khronos Vulkan/OpenCL Bridge for future revision of OpenCL which is still in development:
 190
 191 * <https://www.phoronix.com/scan.php?page=news_item&px=Vulkan-OpenCL-Interop-2019>