3 # REMAP <a name="remap" />
5 * <https://bugs.libre-soc.org/show_bug.cgi?id=143> matrix multiply
6 * <https://bugs.libre-soc.org/show_bug.cgi?id=867> add svindex
7 * <https://bugs.libre-soc.org/show_bug.cgi?id=885> svindex in simulator
8 * see [[sv/remap/appendix]] for examples and usage
9 * see [[sv/propagation]] for a future way to apply REMAP
11 REMAP is an advanced form of Vector "Structure Packing" that
12 provides hardware-level support for commonly-used *nested* loop patterns.
13 For more general reordering an Indexed REMAP mode is available.
15 REMAP allows the usual vector loop `0..VL-1` to be "reshaped" (re-mapped)
16 from a linear form to a 2D or 3D transposed form, or "offset" to permit
17 arbitrary access to elements (when elwidth overrides are used),
18 independently on each Vector src or dest
21 The initial primary motivation of REMAP was for Matrix Multiplication, reordering of sequential
22 data in-place: in-place DCT and FFT were easily justified given the
23 high usage in Computer Science.
24 Four SPRs are provided which may be applied to any GPR, FPR or CR Field
25 so that for example a single FMAC may be
26 used in a single loop to perform 5x3 times 3x4 Matrix multiplication,
27 generating 60 FMACs *without needing explicit assembler unrolling*.
28 Additional uses include regular "Structure Packing"
29 such as RGB pixel data extraction and reforming.
31 REMAP, like all of SV, is abstracted out, meaning that unlike traditional
32 Vector ISAs which would typically only have a limited set of instructions
33 that can be structure-packed (LD/ST typically), REMAP may be applied to
34 literally any instruction: CRs, Arithmetic, Logical, LD/ST, anything.
36 Note that REMAP does not *directly* apply to sub-vector elements: that
37 is what swizzle is for. Swizzle *can* however be applied to the same
38 instruction as REMAP. As explained in [[sv/mv.swizzle]], [[sv/mv.vec]] and the [[svp64/appendix]], Pack and Unpack EXTRA Mode bits
39 can extend down into Sub-vector elements to perform vec2/vec3/vec4
40 sequential reordering, but even here, REMAP is not extended down to
41 the actual sub-vector elements themselves.
43 In its general form, REMAP is quite expensive to set up, and on some
44 implementations may introduce
45 latency, so should realistically be used only where it is worthwhile.
46 Commonly-used patterns such as Matrix Multiply, DCT and FFT have
47 helper instruction options which make REMAP easier to use.
49 There are three types of REMAP:
51 * **Matrix**, also known as 2D and 3D reshaping, can perform in-place
52 Matrix transpose and rotate.
53 * **FFT/DCT**, with full triple-loop in-place support: limited to
55 * **Indexing**, for any general-purpose reordering, also includes
60 * normal vector element read/write of operands would be sequential
62 * this is not appropriate for (e.g.) Matrix multiply which requires
63 accessing elements in alternative sequences (0 3 6 1 4 7 ...)
64 * normal Vector ISAs use either Indexed-MV or Indexed-LD/ST to "cope"
65 with this. both are expensive (copy large vectors, spill through memory)
66 and very few Packed SIMD ISAs cope with non-Power-2.
67 * REMAP **redefines** the order of access according to set "Schedules".
68 * The Schedules are not necessarily restricted to power-of-two boundaries
69 making it unnecessary to have for example specialised 3x4 transpose
72 Only the most commonly-used algorithms in computer science have REMAP
73 support, due to the high cost in both the ISA and in hardware. For
74 arbitrary remapping the `Indexed` REMAP may be used.
76 # Executive Summary Usage
78 * `svshape` to set the type of reordering to be applied to an
79 otherwise usual `0..VL-1` hardware for-loop
80 * `svremap` to set which registers a given reordering is to apply to
82 * `sv.{instruction}` where any Vectorised register marked by `svremap`
83 will have its ordering REMAPPED according to the schedule set
86 The following illustrative example multiplies a 3x4 and a 5x3
91 svremap 15, 1, 2, 3, 0, 0, 0, 0
92 sv.fmadds 0.v, 8.v, 16.v, 0.v
94 * svshape sets up the four SVSHAPE SPRS for a Matrix Schedule
95 * svremap activates four out of five registers RA RB RC RT RS (15)
101 - RS Remapping to not be activated
102 * sv.fmadds has RT=0.v, RA=8.v, RB=16.v, RC=0.v
103 * With REMAP being active each register's element index is
104 *independently* transformed using the specified SHAPEs.
106 Thus the Vector Loop is arranged such that the use of
107 the multiply-and-accumulate instruction executes precisely the required
108 Schedule to perform an in-place in-registers Matrix Multiply with no
109 need to perform additional Transpose or register copy instructions.
110 The example above may be executed as a unit test and demo,
111 [here](https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_matrix.py;h=c15479db9a36055166b6b023c7495f9ca3637333;hb=a17a252e474d5d5bf34026c25a19682e3f2015c3#l94)
115 This section summarises the motivation for each REMAP Schedule
116 and briefly goes over their characteristics and limitations.
117 Further details on the Deterministic Precise-Interruptible algorithms
118 used in these Schedules is found in the [[sv/remap/appendix]].
120 ## Matrix (1D/2D/3D shaping)
122 Matrix Multiplication is a huge part of High-Performance Compute,
124 In many PackedSIMD as well as Scalable Vector ISAs, non-power-of-two
125 Matrix sizes are a serious challenge. PackedSIMD ISAs, in order to
126 cope with for example 3x4 Matrices, recommend rolling data-repetition and loop-unrolling.
127 Aside from the cost of the load on the L1 I-Cache, the trick only
128 works if one of the dimensions X or Y are power-two. Prime Numbers
129 (5x7, 3x5) become deeply problematic to unroll.
131 Even traditional Scalable Vector ISAs have issues with Matrices, often
132 having to perform data Transpose by pushing out through Memory and back,
133 or computing Transposition Indices (costly) then copying to another
136 Matrix REMAP was thus designed to solve these issues by providing Hardware
138 "Schedules" that can view what would otherwise be limited to a strictly
139 linear Vector as instead being 2D (even 3D) *in-place* reordered.
140 With both Transposition and non-power-two being supported the issues
141 faced by other ISAs are mitigated.
143 Limitations of Matrix REMAP are that the Vector Length (VL) is currently
144 restricted to 127: up to 127 FMAs may be performed in total (potentially
145 127 vec2/3/4 FMAs may be used but this requires additional research).
146 Also given that it is in-registers only at present some care has to be
147 taken on regfile resource utilisation. However it is perfectly possible
148 to utilise Matrix REMAP to perform the three inner-most "kernel" loops of
149 the usual 6-level large Matrix Multiply, without the usual difficulties
150 associated with SIMD.
152 Also the `svshape` instruction only provides access to part of the
153 Matrix REMAP capability. Rotation and mirroring need to be done by
154 programming the SVSHAPE SPRs directly, which can take a lot more
157 ## FFT/DCT Triple Loop
159 DCT and FFT are some of the most astonishingly used algorithms in
160 Computer Science. Radar, Audio, Video, R.F. Baseband and dozens more. At least
161 two DSPs, TMS320 and Hexagon, have VLIW instructions specially tailored
164 An in-depth analysis showed that it is possible to do in-place in-register
165 DCT and FFT as long as twin-result "butterfly" instructions are provided.
166 These can be found in the [[openpower/isa/svfparith]] page if performing
167 IEEE754 FP transforms. *(For fixed-point transforms, equivalent 3-in 2-out
168 integer operations would be required)*. These "butterfly" instructions
169 avoid the need for a temporary register because the two array positions
170 being overwritten will be "in-flight" in any In-Order or Out-of-Order
173 DCT and FFT Schedules are currently limited to RADIX2 sizes and do not
174 accept predicate masks. Given that it is common to perform recursive
176 combining smaller Power-2 DCT/FFT to create larger DCT/FFTs in practice the RADIX2
177 limit is not a problem. A Bluestein convolution to compute arbitrary
178 length is demonstrated
179 by [Project Nayuki](https://www.nayuki.io/res/free-small-fft-in-multiple-languages/fft.py)
183 The purpose of Indexing is to provide a generalised version of
184 Vector ISA "Permute" instructions, such as VSX `vperm`. The
185 Indexing is abstracted out and may be applied to much more
186 than an element move/copy, and is not limited for example
187 to the number of bytes that can fit into a VSX register.
188 Indexing may be applied to LD/ST (even on Indexed LD/ST
189 instructions such as `sv.lbzx`), arithmetic operations,
190 extsw: there is no artificial limit.
192 The only major caveat is that the registers to be used as
193 Indices must not be modified by any instruction after Indexed Mode
194 is established, and neither must MAXVL be altered. Additionally,
195 no register used as an Index may exceed MAXVL.
198 these conditions results in `UNDEFINED` behaviour.
199 These conditions allow a Read-After-Write (RAW) Hazard to be created on
200 the entire range of Indices to be subsequently used, but a corresponding
201 Write-After-Read Hazard by any instruction that modifies the Indices
202 **does not have to be created**. Given the large number of registers
203 involved in Indexing this is a huge resource saving and reduction
204 in micro-architectural complexity. MAXVL is likewise
205 included in the RAW Hazards because it is involved in calculating
206 how many registers are to be considered Indices.
208 With these Hazard Mitigations in place, high-performance implementations
209 may read-cache the Indices from the point where a given `svindex` instruction
210 is called (or SVSHAPE SPRs - and MAXVL- directly altered).
212 # REMAP area of SVSTATE
214 The following bits of the SVSTATE SPR are used for REMAP:
216 |32.33|34.35|36.37|38.39|40.41| 42.46 | 62 |
217 | -- | -- | -- | -- | -- | ----- | ------ |
218 |mi0 |mi1 |mi2 |mo0 |mo1 | SVme | RMpst |
220 mi0-2 and mo0-1 each select SVSHAPE0-3 to apply to a given register.
221 mi0-2 apply to RA, RB, RC respectively, as input registers, and
222 likewise mo0-1 apply to output registers (RT/FRT, RS/FRS) respectively.
223 SVme is 5 bits (one for each of mi0-2/mo0-1) and indicates whether the
224 SVSHAPE is actively applied or not.
226 * bit 0 of SVme indicates if mi0 is applied to RA / FRA
227 * bit 1 of SVme indicates if mi1 is applied to RB / FRB
228 * bit 2 of SVme indicates if mi2 is applied to RC / FRC
229 * bit 3 of SVme indicates if mo0 is applied to RT / FRT
230 * bit 4 of SVme indicates if mo1 is applied to Effective Address / FRS / RS
231 (LD/ST-with-update has an implicit 2nd write register, RA)
233 # svremap instruction <a name="svremap"> </a>
235 There is also a corresponding SVRM-Form for the svremap
236 instruction which matches the above SPR:
238 svremap SVme,mi0,mi1,mi2,mo0,mo2,pst
240 |0 |6 |11 |13 |15 |17 |19 |21 | 22.25 |26..31 |
241 | -- | -- | -- | -- | -- | -- | -- | -- | ---- | ----- |
242 | PO | SVme |mi0 | mi1 | mi2 | mo0 | mo1 | pst | rsvd | XO |
244 # SHAPE Remapping SPRs
246 There are four "shape" SPRs, SHAPE0-3, 32-bits in each,
247 which have the same format.
249 [[!inline pages="openpower/sv/shape_table_format" raw="yes" ]]
251 # svshape instruction <a name="svshape"> </a>
253 `svshape` is a convenience instruction that reduces instruction
254 count for common usage patterns, particularly Matrix, DCT and FFT. It sets up
255 (overwrites) all required SVSHAPE SPRs and also modifies SVSTATE
256 including VL and MAXVL. Using `svshape` therefore does not also
259 Form: SVM-Form SV "Matrix" Form (see [[isatables/fields.text]])
261 svshape SVxd,SVyd,SVzd,SVRM,vf
263 | 0.5|6.10 |11.15 |16..20 | 21..25 | 25 | 26..31| name |
264 | -- | -- | --- | ----- | ------ | -- | ------| -------- |
265 |OPCD| SVxd | SVyd | SVzd | SVRM | vf | XO | svstate |
269 * **SVxd** - SV REMAP "xdim"
270 * **SVyd** - SV REMAP "ydim"
271 * **SVzd** - SV REMAP "zdim"
272 * **SVRM** - SV REMAP Mode (0b00000 for Matrix, 0b00001 for FFT etc.)
273 * **vf** - sets "Vertical-First" mode
274 * **XO** - standard 6-bit XO field
276 *Note: SVxd, SVyz and SVzd are all stored "off-by-one". In the assembler
277 mnemonic the values `1-32` are stored in binary as `0b00000..0b11111`*
279 | SVRM | Remap Mode description |
281 | 0b0000 | Matrix 1/2/3D |
282 | 0b0001 | FFT Butterfly |
283 | 0b0010 | DCT Inner butterfly, pre-calculated coefficients |
284 | 0b0011 | DCT Outer butterfly |
285 | 0b0100 | DCT Inner butterfly, on-the-fly (Vertical-First Mode) |
286 | 0b0101 | DCT COS table index generation |
287 | 0b0110 | DCT half-swap |
288 | 0b0111 | reserved |
289 | 0b1000 | reserved |
290 | 0b1001 | reserved |
291 | 0b1010 | iDCT Inner butterfly, pre-calculated coefficients |
292 | 0b1011 | iDCT Outer butterfly |
293 | 0b1100 | iDCT Inner butterfly, on-the-fly (Vertical-First Mode) |
294 | 0b1101 | iDCT COS table index generation |
295 | 0b1110 | iDCT half-swap |
296 | 0b1111 | FFT half-swap |
298 Examples showing how all of these Modes operate exists in the online
299 [SVP64 unit tests](https://git.libre-soc.org/?p=openpower-isa.git;a=tree;f=src/openpower/decoder/isa;hb=HEAD)
300 and the full pseudocode setting up all SPRs
301 is in the [[openpower/isa/simplev]] page.
303 In Indexed Mode, there are only 5 bits available to specify the GPR
304 to use, out of 128 GPRs (7 bit numbering). Therefore, only the top
305 5 bits are given in the `SVxd` field: the bottom two implicit bits
306 will be zero (`SVxd || 0b00`).
308 `svshape` has *limited applicability* due to being a 32-bit instruction.
309 The full capability of SVSHAPE SPRs may be accessed by directly writing
310 to SVSHAPE0-3 with `mtspr`. Circumstances include Matrices with dimensions
311 larger than 32, and in-place Transpose. Potentially a future v3.1 Prefixed
312 instruction, `psvshape`, may extend the capability here.
314 # svindex instruction <a name="svindex"> </a>
316 `svindex` is a convenience instruction that reduces instruction
317 count for Indexed REMAP Mode. It sets up
318 (overwrites) all required SVSHAPE SPRs and can modify the REMAP
319 SPR as well. The relevant SPRs *may* be directly programmed with
320 `mtspr` however it is laborious to do so: svindex saves instructions
321 covering much of Indexed REMAP capability.
323 Form: SVI-Form SV "Indexed" Form (see [[isatables/fields.text]])
325 svindex SVG,rmm,SVd,ew,yx,mr,sk
327 | 0.5|6.10 |11.15 |16.20 | 21..25 | 26..31| name | Form |
328 | -- | -- | --- | ---- | ----------- | ------| -------- | ---- |
329 |OPCD| SVG | rmm | SVd | ew/yx/mm/sk | XO | svindex | SVI-Form |
333 * **SVd** - SV REMAP x/y dim
334 * **rmm** - REMAP mask: sets remap mi0-2/mo0-1 and SVSHAPEs,
336 * **ew** - sets element width override on RS
337 * **SVG** - GPR SVG<<2 to be used for Indexing
338 * **yx** - 2D reordering to be used if yx=1
339 * **mm** - mask mode. determines how `rmm` is interpreted.
340 * **sk** - Dimension skipping enabled
341 * **XO** - standard 6-bit XO field
343 *Note: SVd, like SVxd, SVyz and SVzd of `svshape`, are all stored
344 "off-by-one". In the assembler
345 mnemonic the values `1-32` are stored in binary as `0b00000..0b11111`*.
347 *Note: when `yx=1,sk=0` the second dimension is calculated as
352 * `rmm`, like REMAP.SVme, has bit 0
353 correspond to mi0, bit 1 to mi1, bit 2 to mi2,
354 bit 3 to mo0 and bit 4 to mi1
355 * all SVSHAPEs and the REMAP parts of SVSHAPE are first reset (initialised to zero)
356 * for each bit set in the 5-bit `rmm`, in order, the first
357 as-yet-unset SVSHAPE will be updated
358 with the other operands in the instruction, and the REMAP
360 * If all 5 bits of `rmm` are set then both mi0 and mo1 use SVSHAPE0.
361 * SVSTATE persistence bit is cleared
362 * No other alterations to SVSTATE are carried out
364 Example 1: if rmm=0b00110 then SVSHAPE0 and SVSHAPE1 are set up,
365 and the REMAP SPR set so that mi1 uses SVSHAPE0 and mi2
366 uses mi2. REMAP.SVme is also set to 0b00110, REMAP.mi1=0
367 (SVSHAPE0) and REMAP.mi2=1 (SVSHAPE1)
369 Example 2: if rmm=0b10001 then again SVSHAPE0 and SVSHAPE1
370 are set up, but the REMAP SPR is set so that mi0 uses SVSHAPE0
371 and mo1 uses SVSHAPE1. REMAP.SVme=0b10001, REMAP.mi0=0, REMAP.mo1=1
373 Rough algorithmic form:
375 marray = [mi0, mi1, mi2, mo0, mo1]
378 if not rmm[bit]: continue
380 SVSTATE{marray[bit]} = idx
381 idx = (idx+1) modulo 4
385 * bits 0-2 (MSB0 numbering) of `rmm` indicate an index selecting mi0-mo1
386 * bits 3-4 (MSB0 numbering) of `rmm` indicate which SVSHAPE 0-3 shall
388 * only the selected SVSHAPE is overwritten
389 * only the relevant bits in the REMAP area of SVSTATE are updated
390 * REMAP persistence bit is set.
392 Example 1: if `rmm`=0b01110 then bits 0-2 (MSB0) are 0b011 and
393 bits 3-4 are 0b10. thus, mo0 is selected and SVSHAPE2
394 to be updated. REMAP.SVme[3] will be set high and REMAP.mo0
397 Example 2: if `rmm`=0b10011 then bits 0-2 (MSB0) are 0b100 and
398 bits 3-4 are 0b11. thus, mo1 is selected and SVSHAPE3
399 to be updated. REMAP.SVme[4] will be set high and REMAP.mo1
402 Rough algorithmic form:
404 marray = [mi0, mi1, mi2, mo0, mo1]
408 SVSTATE{marray[bit]} = idx
411 In essence, `mm=0` is intended for use to set as much of the
412 REMAP State SPRs as practical with a single instruction,
413 whilst `mm=1` is intended to be a little more refined.
417 * **Disable 2D mapping**: to only perform Indexing without
418 reordering use `SVd=1,sk=0,yx=0` (or set SVd to a value larger
420 * **Modulo 1D mapping**: to perform Indexing cycling through the
421 first N Indices use `SVd=N,sk=0,yx=0` where `VL>N`. There is
422 no requirement to set VL equal to a multiple of N.
423 * **Modulo 2D transposed**: `SVd=M,sk=0,yx=1`, sets
424 `xdim=M,ydim=CEIL(MAXVL/M)`.
426 Beyond these mappings it becomes necessary to write directly to
427 the SVSTATE SPRs manually.
432 * investigate https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6879380/#!po=19.6429
433 in https://bugs.libre-soc.org/show_bug.cgi?id=653
434 * UTF-8 <https://bugs.libre-soc.org/show_bug.cgi?id=794>
436 * Cross-Product REMAP (actually, skew Matrix: https://en.m.wikipedia.org/wiki/Skew-symmetric_matrix)