X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;f=shakti%2Fm_class%2Flibre_3d_gpu.mdwn;h=4c001382026c5520668c0db4cf504d457e842e96;hb=fe095ace2d0f82e9405e2699eb106d3b53e5de0c;hp=5e3b6e9f2e5e92b2ad8fdd0b8c232652b60e04a9;hpb=aa19b66b92d6f9b6a1df8834a7554602b61d692d;p=libreriscv.git

diff --git a/shakti/m_class/libre_3d_gpu.mdwn b/shakti/m_class/libre_3d_gpu.mdwn
index 5e3b6e9f2..4c0013820 100644
--- a/shakti/m_class/libre_3d_gpu.mdwn
+++ b/shakti/m_class/libre_3d_gpu.mdwn
@@ -1,6 +1,6 @@
 # Libre 3D GPU Requirements
 
-## GPU 3D capabilities
+## GPU capabilities
 
 Based on GC800 the following would be acceptable performance (as would Mali-400):
 
@@ -75,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),