(no commit message)

[libreriscv.git] / shakti / m_class / libre_3d_gpu.mdwn

diff --git a/shakti/m_class/libre_3d_gpu.mdwn b/shakti/m_class/libre_3d_gpu.mdwn
index a6e2a29b367b16a659e1e156020904f91c5c5a80..479ec2fed9338f5c93fe7915b63c75ebe49a72f6 100644 (file)
--- a/shakti/m_class/libre_3d_gpu.mdwn
+++ b/shakti/m_class/libre_3d_gpu.mdwn
@@ -1,8 +1,6 @@
-# Requirements
+# Libre 3D GPU Requirements
 
-test
-
-## GPU 3D capabilities
+## GPU capabilities
 
 Based on GC800 the following would be acceptable performance (as would Mali-400):
 
@@ -43,7 +41,7 @@ same silicon area).
 * Hardware (RTL) must be licensed under BSD or MIT with no
   "NON-COMMERCIAL" CLAUSES.
 * Any proposals will be competing against Vivante GC800 (using Etnaviv driver).
-* The GPU is integrated (like Mali400). So all that the GPU needs to do is write to an area of memory (framebuffer or area of the framebuffer). The SoC - which in this case has a RISC-V core and has peripherals such as the LCD controller - will take care of the rest.
+* The GPU is integrated (like Mali-400). So all that the GPU needs to do is write to an area of memory (framebuffer or area of the framebuffer). The SoC - which in this case has a RISC-V core and has peripherals such as the LCD controller - will take care of the rest.
 * In this arcitecture, the GPU, the CPU and the peripherals are all on the same AXI4 shared memory bus. They all have access to the same shared DDR3/DDR4 RAM. So as a result the GPU will use AXI4 to write directly to the framebuffer and the rest will be handle by SoC.
 * The job must be done by a team that shows sufficient expertise to reduce the risk.
 
@@ -77,7 +75,13 @@ has a *software* (LLVM) renderer:
 The general aim of this approach is *not* to have the complexity of
 transferring significant amounts of data structures to and from disparate
 cores (one Nyuzi, one RISC-V) but to STAY WITHIN THE RISC-V ARCHITECTURE
-and simply compile Mesa3D (for RISC-V), gallium3d-llvm (for RISC-V).
+and simply compile Mesa3D (for RISC-V), gallium3d-llvm (for RISC-V),
+modifying llvm for RISC-V to do the heavy-lifting instead.
+
+Then it just becomes a matter of adding vector / SIMD / parallelisation
+extensions to RISC-V, and adding support in LLVM for the same:
+
+<https://lists.llvm.org/pipermail/llvm-dev/2018-April/122517.html>
 
 So if considering to base the design on RISC-V, that means turning RISC-V
 into a vector processor. Now, whilst Hwacha has been located (finally),