From: lkcl Date: Sun, 8 May 2022 19:20:20 +0000 (+0100) Subject: (no commit message) X-Git-Tag: opf_rfc_ls005_v1~2300 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=265aef9a3a88162ee10c1de9e1b42f46994c5895;p=libreriscv.git --- diff --git a/openpower/sv/SimpleV_rationale.mdwn b/openpower/sv/SimpleV_rationale.mdwn index 85116aced..69237ee8f 100644 --- a/openpower/sv/SimpleV_rationale.mdwn +++ b/openpower/sv/SimpleV_rationale.mdwn @@ -841,7 +841,11 @@ CPU as a software-extension. **Use-case: Matrix and Convolutions** Imagine a large Matrix scenario, with several values close to zero that -could be skipped: no need to include zero-multiplications. +could be skipped: no need to include zero-multiplications, but a +traditional CPU in no way can help: only by loading the data through +the L1-L4 Cache and Virtual Memory Barriers is it possible to +ascertain, retrospectively, that time and power had just been wasted. + SVP64 is able to do what is termed "Vertical-First" Vectorisation, combined with SVREMAP Matrix Schedules. Imagine that SVREMAP has been extended, Snitch-style, to perform a deterministic memory-array walk of @@ -849,8 +853,9 @@ a large Matrix. Let us also imagine that the Matrices are stored in Memory with PEs attached, and that the PEs are fully functioning Power ISA with Draft -SVP64 their Multiply capability is not as good as the main CPU. Therefore: -we want the PEs to feed the sparse data to the main CPU. +SVP64, but their Multiply capability is not as good as the main CPU. +Therefore: +we want the PEs to feed the sparse data to the main CPU, a la "Extra-V". * The ZOLC SVREMAP System running on the main CPU generates a Matrix Memory-Load Schedule.