(no commit message)
[libreriscv.git] / simple_v_extension / open_3d_alliance_2019aug26.tex
index f3c042baa9f84c5a731578d076a606e761f9090c..c95bc70eb3b36e03a352577dd1ceadf83ca718cd 100644 (file)
@@ -52,7 +52,7 @@
 \frame{\frametitle{Libre RISC-V Team}
 
  \begin{itemize}
-   \item Small team, sponsored by Purism and the NLNet Foundation\vspace{8pt}
+   \item Small team, sponsored by Purism and the NLnet Foundation\vspace{8pt}
    \item Therefore, focus is on efficiency: leap-frogging ahead\\
             without requiring huge resources.\vspace{8pt}
    \item OpenGL API? Gallium3D / Vulkan is better\vspace{8pt}
 
  \begin{itemize}
    \item The software, basically.  Anything other than Vulkan\\
-            is a 10+ man-year effort\vspace{12pt}
+            is a 10+ man-year effort
+   \item Two new 3D "platforms".  Vulkan compliance has implications\\
+            for hardware, and, with the API being public, interoperability\\
+            (and Khronos Compliance - which is Trademarked) is critical.
    \item Respecting that standards are hard to get right\\
          (and that consequences of mistakes are severe:\\
-         no opportunity for corrections after a freeze)\vspace{12pt}
+         no opportunity for corrections after a freeze)
    \item Respecting that, for collaboration and interoperability,\\
-         some things go into a standard that you might not "need"\vspace{12pt}
+         some things go into a standard that you might not "need"
    \item Mutually respectful open and fully transparent collaboration.\\
          No NDAs, no "closed forums".  We need the help of experts\\
          (such as Mitch Alsup) in this highly technical specialist area.
   \end{itemize}
 }
 
+\frame{\frametitle{Why Two new Platforms?}
+
+ \begin{itemize}
+   \item Unique pragmatic consequences of "Hybrid" CPU/GPU
+   \item Embedded - no traps need be raised. Interoperability is\\ 
+   impossible, software toolchain collaboration is incidental).
+   \item UNIX - illegal instruction traps mandatory: software\\
+   interoperability is mandatory and essential.
+   \item 3D Embedded - failure to allow implementors the freedom\\
+   to reduce FP accuracy automatically results in product failure\\
+   (too many gates, too much power, equals end-user rejection).
+   \item 3D UNIX - likewise.  Also: failure to comply with Khronos\\
+   Specifications (then use "Vulkan") is a Trademark violation.
+   \item Solution: allow software to select FP accuracy level\\
+   \textbf{at runtime}. (UNIX Platform: IEEE754. 3D UNIX: Vulkan).\\
+   \item HW: slow for IEEE754, fast for 3D. Product now competitive!
+ \end{itemize}
+}
+
 \frame{\frametitle{What has our team done already?}
 
  \begin{itemize}
    \item Decided to go the "Hybrid" Route (Separate GPUs requires a\\
          full-blown RPC/IPC mechanism to transfer all 3D API calls\\
          to and from userspace memory to GPU memory... and back).
-   \item Developed Simple-V (a "Parallelising API)\\
+   \item Developed Simple-V (a "Parallelising" API)\\
                 (Simple-V is very hard to describe, because it is unique:\\
                 there is no common Computer Science terminology)
    \item Started on Kazan (a Vulkan SPIR-V to LLVM compiler)
             with help from Mitch Alsup, the designer of the M68000
    \item Variable-issue, predicated SIMD backend, Vector front-end\\
             "precise" exceptions, branch shadowing, much more
+   \item All Libre-licensed and developed publicly and transparently.
   \end{itemize}
 }
 
 \frame{\frametitle{Why Simple-V? Why not RVV?}
 
  \begin{itemize}
-   \item RVV is designed exclusively for supercomputing\vspace{8pt}
+   \item RVV is designed exclusively for supercomputing\\
+         (RVV simply has not been designed with 3D in mind).
    \item Like SIMD, RVV uses dedicated opcodes\\
-            (google "SIMD considered harmful")\vspace{8pt}
+            (google "SIMD considered harmful")
    \item 98\% of FP opcodes are duplicated in RVV. Large portion\\
-         of BitManip opcodes duplicated in predicate Masks\vspace{8pt}
+         of BitManip opcodes duplicated in predicate Masks
    \item OP32 space is extremely precious: 48 and 64 bit opcode space\\
-         comes with an inherent I-Cache power consumption penalty\vspace{8pt}
+         comes with an inherent I-Cache power consumption penalty
    \item Simple-V "prefixes" scalar opcodes (all of them)\\
             No need for any new "vector" opcodes (at all).\\
-            Can therefore use the RVV major opcode for 3D\vspace{8pt}
+            Can therefore use the RVV major opcode for 3D
+   \item SV augments "scalar" opcodes. Implications: it is relatively\\
+            straightforward to convert an \textit{existing design} to SV.\\
+            SV "slots in" between instruction decode and the ALU.
   \end{itemize}
 }
 
    \item With a custom specialised SPIR-V (Vulkan) Compiler\\
          being an absolutely critical strategic requirement,\\
          RVV and its associated compiler (still not developed)\\
-         is, surprisingly, of marginal value.
+         is of marginal value (no clear benefits, extra cost)
    \item Question everything!  Your input, and a willingness to\\
             take active responsibility for tasks that your Company\\
             is critically dependent on, are extremely important.