X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;f=nlnet_2019_amdvlk_port.mdwn;h=07e2f0a03f5d16c2e3032776ec8ba29e4dd3aa4e;hb=367bd556802220231196bb05c0b8ff76a45338ed;hp=1d67d725db1973b3d2e276538244ce24216d6630;hpb=4c23dff9d0aeb14e204e87936e1babd12d6801ce;p=libreriscv.git
diff --git a/nlnet_2019_amdvlk_port.mdwn b/nlnet_2019_amdvlk_port.mdwn
index 1d67d725d..07e2f0a03 100644
--- a/nlnet_2019_amdvlk_port.mdwn
+++ b/nlnet_2019_amdvlk_port.mdwn
@@ -1,8 +1,12 @@
-# NL.net proposal
+# NL.net proposal 2019-10-042
+
+* [[questions]]
+* NLNet Project page
+* Top Level bugreport
## Project name
-Port of AMDVLK 3D Driver to the Libre RISC-V SoC
+Port of AMDVLK/RADV 3D Driver to the Libre RISC-V SoC
## Website / wiki
@@ -31,8 +35,14 @@ shows that it would be relatively straightforward to replace the libraries
that generate Radeon GPU assembly code with ones that generate assembly
for the Libre RISC-V SoC, instead.
-Thus we intend to do exactly that: leverage AMD's excellent work to create
-a libre-licensed commercial-grade Vulkan 3D driver that takes full advantage
+In addition, further investigation shows that RADV, the libre-licensed
+MESA 3D Driver, also supports SPIR-V (by way of conversion to MESA NIR),
+and, likewise, may be a good candidate for replacing Radeon with Libre
+RISC-V assembly.
+
+Thus we intend to do exactly that: leverage the excellent work already
+done to create a libre-licensed commercial-grade Vulkan 3D driver that
+takes full advantage
of the parallelism and Vectorisation in the hybrid Libre RISC-V SoC.
# 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?
@@ -54,13 +64,17 @@ EUR 50,000.
# Explain what the requested budget will be used for?
-We are aiming for a multi-stage process, starting with the basics:
-
-* The first stage is to remove AMD's "PAL" Library and replace it with
- a straightforward upstream port of the current LLVM JIT compiler,
- alongside a "support" library that will call OpenCL / OpenGL
- functions directly on the main processor. This "effectively"
- turns AMDVLK into a peer of google swiftshader (a "Software 3D Renderer").
+After a thorough and comprehensive evaluation to see which will be the
+best to choose (RADV or AMDVLK), we are aiming for a multi-stage process,
+starting with the basics:
+
+* The first stage is to remove AMD's "PAL" Library in AMDVLK, or the
+ AMDGPU engine used in RADV, and replace it with a straightforward
+ upstream port of the current LLVM JIT compiler, alongside a "support"
+ library that will call OpenCL / OpenGL functions directly on the main
+ processor. This "effectively" turns the engine into a peer of google
+ swiftshader (a "Software 3D Renderer") which will allow us to carry out
+ rapid testing on stable x86 systems before moving on to the next stage.
* The second stage is to confirm that the standard RISC-V LLVM JIT
(which was recently upstreamed as of LLVM 9.0.0) is properly functional
under an emulator or other RV64GC system.
@@ -89,11 +103,12 @@ other not only difficult but potentially a costly mistake.
# Compare your own project with existing or historical efforts.
Nyuzi is a Software-based 3D Engine that has an LLVM port. The problem
-is that it has deliberately been designed to be a software-only Vector
-Processor. As such, with no custom accelerated opcodes dedicated to 3D,
-its power-performance metric is a whopping 25% that of commercially-acceptable
-3D GPUs. It also has no actual 3D Vulkan Driver: the developers focussed
-only on the "core algorithms".
+is that it has deliberately been designed to be a software-only
+Vector Processor. As such, with no custom accelerated opcodes
+dedicated to 3D, its power-performance metric is a whopping 25% that of
+commercially-acceptable 3D GPUs. It also has no actual 3D Vulkan Driver:
+the developers focussed only on the "core algorithms" as part of an
+(extremely useful) academic exercise, only.
Google's swiftshader is a software-based 3D Driver/Engine that is compatible
with at least one version of Vulkan. On the face of it, this would be a
@@ -105,6 +120,12 @@ known to give a massive 400% power penalty. Not only that, but our
additions would not be welcome due to the primary focus of swiftshader
being on non-hardware-accelerated, non-custom processors.
+RADV is the free software competitor to AMDVLK. It takes a different
+route: converting SPIR-V to NIR (New Internal Representation) which will
+need close evaluation to ensure that it's directly suited to Vector
+Processing. Like AMDVLK, it does not directly support RISC-V: it was
+purely intended to support Radeon GPUs.
+
Our initial proposal - Kazan - is much more interesting to discern and
compare against. Kazan is being specifically designed so that the
SPIR-V compiler is capable of fully supporting "full-function vectorisation".
@@ -130,9 +151,9 @@ because it is just not possible to predict in advance which would be "better".
## What are significant technical challenges you expect to solve during the project, if any?
This is compiler technology, which is traditionally viewed as particularly
-challenging. We are slightly fortunate in that much of the pieces of the
-puzzle already exist: AMDVLK, the upstreamed acceptance of RISC-V LLVM 9.0.0
-being the key ones.
+challenging. We are slightly fortunate in that much of the pieces of
+the puzzle already exist: AMDVLK, RADV, the upstreamed acceptance of
+RISC-V LLVM 9.0.0 being the key ones.
Whilst we know *technically* what they did and why they did it, the key
challenge will be to unravel what exact changes AMD made which caused
@@ -141,6 +162,10 @@ efforts to introduce "mainline" LLVM patches on an ongoing piecemeal
basis, and at the same time *add our own assembler back-end* into the
same fast-moving target.
+Whereas with RADV it is upstreamed in MESA, and has much wider community
+support, it will need very careful detailed evaluation to ensure that it meets
+the needs of the Libre RISC-V Vector Engine.
+
## 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
@@ -161,3 +186,8 @@ all picked up the story. The list is updated and maintained here:
*
*
*
+*
+
+# Management Summary
+
+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.