X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;f=nlnet_2019_amdvlk_port.mdwn;h=07e2f0a03f5d16c2e3032776ec8ba29e4dd3aa4e;hb=a008f8d2bdc86945a3e41c777eb4dd6fb734d0b7;hp=c5cba7cd4cbdb01305ef6059df4de2923d6b5137;hpb=7f1a84d5a9722a3b8db32a773d37950fe036bb45;p=libreriscv.git
diff --git a/nlnet_2019_amdvlk_port.mdwn b/nlnet_2019_amdvlk_port.mdwn
index c5cba7cd4..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,15 +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")
- which will allow us to carry out rapid testing on stable x86 systems before
- moving on to the next stage.
+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.
@@ -108,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".
@@ -133,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
@@ -144,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
@@ -164,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.