From 4577994092b843bb0f00dd4a7a49209060aece19 Mon Sep 17 00:00:00 2001 From: lkcl Date: Sun, 8 May 2022 07:09:12 +0100 Subject: [PATCH] --- openpower/sv/SimpleV_rationale.mdwn | 64 ++++++++++++++--------------- 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/openpower/sv/SimpleV_rationale.mdwn b/openpower/sv/SimpleV_rationale.mdwn index 97954ed1f..1422cbbbd 100644 --- a/openpower/sv/SimpleV_rationale.mdwn +++ b/openpower/sv/SimpleV_rationale.mdwn @@ -804,38 +804,6 @@ Intel, ARM, MIPS, Power ISA and RISC-V have all already said "yes" on that, for several decades, and advanced programmers are comfortable with the practice. -**Roadmap summary of Advanced SVP64** - -The future direction for SVP64, then, is: - -* To overcome its current limitation of REMAP Schedules being - restricted to Register Files, leveraging the Snitch-style - register interception "tagging" technique. -* To adopt ZOLC and merge REMAP Schedules into ZOLC -* To bring OpenCAPI Memory Access into ZOLC as a first-level - concept that mirrors Snitch's Coherent Memory interception -* To add the Graph-Node Walking Capability of Extra-V - to ZOLC / SVREMAP -* To make it possible, in a combination of hardware and software, - to easily identify ZOLC / SVREMAP Blocks - that may be transparently pushed down closer to Memory, for - localised distributed parallel execution, by OpenCAPI-aware PEs, - exploiting both the Deterministic nature of ZOLC / SVREMAP - combined with the Cache-Coherent nature of OpenCAPI, - to the maximum extent possible. -* To make the exploitation of this powerful solution as simple - and straightforward as possible for Software Engineers to use, - in standard common-usage compilers, gcc and llvm. -* To propose extensions to Public Standards that allow all of - the above to become part of everyday ubiquitous mass-volume - computing. - -Even the first of these - merging Snitch-style register tagging -into SVP64 - would -expand SVP64's capability for Matrices, currently limited to -around 5x7 to 6x6 Matrices and constrained by the size of -the register files (128 64-bit entries), to arbitrary (massive) sizes. - **Use-case: Matrix and Convolutions** Imagine a large Matrix scenario, with several values close to zero that @@ -870,6 +838,38 @@ main CPU. In this way a large Sparse Matrix Multiply or Convolution may be achieved without having to pass unnecessary data through L1/L2/L3 Caches only to find, at the CPU, that it is zero. +**Roadmap summary of Advanced SVP64** + +The future direction for SVP64, then, is: + +* To overcome its current limitation of REMAP Schedules being + restricted to Register Files, leveraging the Snitch-style + register interception "tagging" technique. +* To adopt ZOLC and merge REMAP Schedules into ZOLC +* To bring OpenCAPI Memory Access into ZOLC as a first-level + concept that mirrors Snitch's Coherent Memory interception +* To add the Graph-Node Walking Capability of Extra-V + to ZOLC / SVREMAP +* To make it possible, in a combination of hardware and software, + to easily identify ZOLC / SVREMAP Blocks + that may be transparently pushed down closer to Memory, for + localised distributed parallel execution, by OpenCAPI-aware PEs, + exploiting both the Deterministic nature of ZOLC / SVREMAP + combined with the Cache-Coherent nature of OpenCAPI, + to the maximum extent possible. +* To make the exploitation of this powerful solution as simple + and straightforward as possible for Software Engineers to use, + in standard common-usage compilers, gcc and llvm. +* To propose extensions to Public Standards that allow all of + the above to become part of everyday ubiquitous mass-volume + computing. + +Even the first of these - merging Snitch-style register tagging +into SVP64 - would +expand SVP64's capability for Matrices, currently limited to +around 5x7 to 6x6 Matrices and constrained by the size of +the register files (128 64-bit entries), to arbitrary (massive) sizes. + **Summary** Bottom line is that there is a clear roadmap towards solving a long -- 2.30.2