From e4197a27ddb09bdc1e67ba02c810f94ea9b8a90e Mon Sep 17 00:00:00 2001 From: Luke Kenneth Casson Leighton Date: Sat, 28 Sep 2019 14:22:38 +0100 Subject: [PATCH] add nlnet opencl proposal --- nlnet_2019_opencl.md | 186 +++++++++++++++++++++++++++++++++++++++++++ resources.mdwn | 7 +- 2 files changed, 190 insertions(+), 3 deletions(-) create mode 100644 nlnet_2019_opencl.md diff --git a/nlnet_2019_opencl.md b/nlnet_2019_opencl.md new file mode 100644 index 000000000..52d54ec49 --- /dev/null +++ b/nlnet_2019_opencl.md @@ -0,0 +1,186 @@ +# NL.net proposal + +## Project name + +OpenCL hardware support on Libre RISC-V + +## Website / wiki + + + +Please be short and to the point in your answers; focus primarily on +the what and how, not so much on the why. Add longer descriptions as +attachments (see below). If English isn't your first language, don't +worry - our reviewers don't care about spelling errors, only about +great ideas. We apologise for the inconvenience of having to submit in +English. On the up side, you can be as technical as you need to be (but +you don't have to). Do stay concrete. Use plain text in your reply only, +if you need any HTML to make your point please include this as attachment. + +## Abstract: Can you explain the whole project and its expected outcome(s). + +The Libre RISC-V SoC is being developed to provide a privacy-respecting +modern processor, developed transparently and as libre to the bedrock +as possible. + +As a hybrid processor, it is intended to be both a CPU +*and* a GPU. GPUs are normally proprietary (and thus are perfect candidate +attack vectors), as is the low-level software that runs on it. + +Despite the original meaning of GPU, GPUs are not only limited to graphics +processing. In fact, there is a quite common use case of using GPUs for +more general computation these days. The work of scientists, AI and ML +developers, multimedia applications such as FFmpeg, etc., depend on +unique traits of GPUs to accelerate their processing. A standard, open API +to facilitate this is OpenCL. + +Almost all the major mobile-class GPUs, such as Vivante GC, ARM Mali, +Broadcom VideoCore, and Qualcomm Adreno, support OpenCL, but of course +they are proprietary implementations which cannot be trusted completely. + +While the mobile-class GPUs have terrible open-source support, at least +the bigger GPU names such as AMD and Intel have open-sourced their OpenCL +solutions. In addition, since we are reusing the SPIR-V/LLVM/Mesa stack +for Vulkan (as detailed in our AMDVLK/RADV NlNet proposal) and OpenGL +support, Mesa also happens to come with an OpenCL implementation which +we can possibly reuse as well (Gallium/Clover). + +However, these OpenCL implementations tend to be very specific to the +vendors processors so we will have to investigate which pieces to reuse +and develop our own specific implementation. Furthermore, we cannot +infinitely delay our first iteration of the Libre RISC-V SoC. Therefore, +this proposal is limited to only doing the hardware requirements of +OpenCL first. In a future proposal for the second iteration of +Libre RISC-V, we will work on the software requirements of OpenCL. + +Thus we intend to do exactly that: leverage the excellent work already +done to create a libre-licensed commercial-grade OpenCL driver that +takes full advantage of the parallelism and vectorisation in the +hybrid Libre RISC-V SoC to accelerate compute applications. + +# 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? + +Luke Leighton is an ethical technology specialist who has a consistent +24-year track record of developing code in a real-time transparent +(fully libre) fashion, and in managing Software Libre teams. He is the +lead developer on the Libre RISC-V SoC. + +Jacob Lifshay is a software libre 3D expert who developed a Vulkan 3D +software render engine under the GSoc2017 Programme. He also developed +his own libre-licensed 32-bit RISC-V processor, and has written an +optimising javascript compiler. Jacob is a valuable member of the team and is +working on Kazan (https://salsa.debian.org/Kazan-team/kazan) + +# Requested Amount + +EUR 50,000. + +# Explain what the requested budget will be used for? + +After a thorough and comprehensive evaluation to see which will be the +best to choose (Intel NEO, AMD ROCm, Mesa Gallium/Clover), we are aiming +for a multi-stage process, starting with the basics: + +* The first stage is to make sure we have the necessary hardware + support for hardware acceleration of OpenCL. OpenCL would be pointless + if all done in software. +* The second stage (in a future proposal) is to create a basic OpenCL + driver by looking at how other OpenCL implementations are done. +* The third phase (in a future proposal) will be to begin the iterative + process, to experiment in both a software simulator as well as in FPGAs, + with the addition of both vectorisation as well as custom opcodes that + will significantly improve performance as well as meet + commercially-acceptable power-performance demands. + +At the point where commercial power-performance requirements are met and +OpenCL applications are able to run on Libre RISC-V without software +emulation, we may officially declare the project a "success". + +# Does the project have other funding sources, both past and present? + +The overall project has sponsorship from Purism as well as a prior +grant from NLNet. However that is for specifically covering the +development of the RTL (the hardware source code). + +Actual development of OpenCL drivers, accelerated by the capabilities +of this hybrid design, was not part of the original proposal. + +A previous proposal supported the creation of Kazan which will serve +as a Vulkan graphics driver. While Vulkan does have some compute +capabilities, its use is limited to the graphics domain. This OpenCL +driver will allow for full compute cabilities on Libre RISC-V. + +# Compare your own project with existing or historical efforts. + +The Vivante GC800 is capable of OpenCL but as many other mobile-class +GPUs, it is proprietary. + +The Broadcom VideoCore GPU used in Raspberry Pis are also capable of OpenCL. +In the future, it is very likely that Libre RISC-V will be used to create +a Single-board computer (SBC) just like a Raspberry Pi (possibly by us or +third-party). + +Intel's NEO is a modern OpenCL driver that leverages an LLVM-based graphics +compiler stack to provide OpenCL usage for Intel GPUs. Compared to other +OpenCL implementations, the community considers Intel's to be the best one +and NEO also is compliant with the latest OpenCL standard at 2.2. + +AMD's ROCm not only provides an OpenCL driver, but also AMD's own specific +compute stack that deviates from OpenCL. ROCm supports an older version +of OpenCL 2.0 but not higher. + +Kazan is our Vulkan graphics driver. While Vulkan can be used for a limited +set of compute functionality geared towards graphics use-cases, Vulkan is +not meant to be used for general-purpose compute. + +There are also some open-source projects (clvk, clspv) to adapt OpenCL on +Vulkan, however, given that Vulkan is a completely different API than OpenCL, +there will likely be drawbacks to this approach as well as a performance +penalty for not having OpenCL support in hardware. Moreover, clvk and clspv +only support OpenCL 1.2. + +Nvidia has very limited OpenCL support due mainly to the fact that they have +a competing compute solution called CUDA. As such, they are stuck on OpenCL 1.2 +in order to promote their own proprietary API instead. As a libre project, +we cannot support a closed solution such as CUDA and instead we will support +the alternative open Khronos standard for compute - OpenCL. + +## What are significant technical challenges you expect to solve during the project, if any? + +There are many levels to supporting OpenCL. This proposal is only meant for +funding the development of hardware acceleration for OpenCL which should be +relatively easier to do given that Vulkan and OpenCL share some low-level +details. + +A future proposal will detail the software side which will require *far* more +engineering resources because we will have to handle the runtime and compiler +technology for the OpenCL driver. + +## Describe the ecosystem of the project, and how you will engage with relevant actors and promote the outcomes? + +As mentioned in the 2018 submission, the Libre RISC-V +SoC has a full set of resources for Libre Project Management and development: +mailing list, bugtracker, git repository and wiki - all listed here: + + +In addition, we have a Crowdsupply page + which provides a public +gateway, and heise.de, reddit, phoronix, slashdot and other locations have +all picked up the story. The list is updated and maintained here: + + +# Extra info to be submitted + +Applications of OpenCL/GPGPU: +* +* +* + +Implementations: +* Intel Neo +* AMD ROCm +* Google clspv +* clvk +* Mesa OpenCL +* + diff --git a/resources.mdwn b/resources.mdwn index 4a99fc590..6e5f92337 100644 --- a/resources.mdwn +++ b/resources.mdwn @@ -154,9 +154,10 @@ do the paperwork, and pay the relevant fees. ## Formal Verification -Formal verification of Libre RISC-V ensures that it is bug-free in regards to what we specify. -Of course, it is important to do the formal verification as a final step in the development process before -we produce thousands or millions of silicon. +Formal verification of Libre RISC-V ensures that it is bug-free in +regards to what we specify. Of course, it is important to do the formal +verification as a final step in the development process before we produce +thousands or millions of silicon. Some learning resources I found in the community: -- 2.30.2