(no commit message)
[libreriscv.git] / openpower / sv.mdwn
1 [[!tag standards]]
2
3 # Simple-V Vectorisation for the OpenPOWER ISA
4
5 **SV is in DRAFT STATUS**. SV has not yet been submitted to the OpenPOWER Foundation ISA WG for review.
6
7 <https://bugs.libre-soc.org/show_bug.cgi?id=213>
8
9 SV is designed as a Vector ISA for Hybrid 3D CPU GPU VPU workloads.
10 As such it brings features normally only found in Cray Supercomputers
11 (Cray-1, NEC SX-Aurora)
12 and in GPUs, but keeps strictly to a *Simple* principle of leveraging
13 a *Scalar* ISA, exclisively using "Prefixing". **Not one single actual
14 explicit Vector opcode exists in SV, at all**.
15
16 Fundamental design principles:
17
18 * Simplicity of introduction and implementation on the existing OpenPOWER ISA
19 * Effectively a hardware for-loop, pausing PC, issuing multiple scalar operations
20 * Preserving the underlying scalar execution dependencies as if the for-loop had been expanded as actual scalar instructions
21 (termed "preserving Program Order")
22 * Augments ("tags") existing instructions, providing Vectorisation "context" rather than adding new ones.
23 * Does not modify or deviate from the underlying scalar OpenPOWER ISA unless it provides significant performance or other advantage to do so in the Vector space (dropping XER.SO and OE=1 for example)
24 * Designed for Supercomputing: avoids creating significant sequential
25 dependency hazards, allowing high performance superscalar microarchitectures to be deployed.
26
27 Advantages of these design principles:
28
29 * It is therefore easy to create a first (and sometimes only) implementation as literally a for-loop in hardware, simulators, and compilers.
30 * Hardware Architects may understand and implement SV as being an
31 extra pipeline stage, inserted between decode and issue, that is
32 a simple for-loop issuing element-level sub-instructions.
33 * More complex HDL can be done by repeating existing scalar ALUs and
34 pipelines as blocks and leveraging existing Multi-Issue Infrastructure
35 * As (mostly) a high-level "context" that does not (significantly) deviate from scalar OpenPOWER ISA and, in its purest form being "a for loop around scalar instructions", it is minimally-disruptive and consequently stands a reasonable chance of broad community adoption and acceptance
36 * Completely wipes not just SIMD opcode proliferation off the
37 map (SIMD is O(N^6) opcode proliferation)
38 but off of Vectorisation ISAs as well. No more separate Vector
39 instructions.
40
41 Pages being developed and examples
42
43 * [[sv/overview]] explaining the basics.
44 * [[sv/implementation]] implementation planning and coordination
45 * [[sv/svp64]] contains the packet-format *only*
46 * [[sv/setvl]] the Cray-style "Vector Length" instruction
47 * [[sv/svp64_quirks]] things in SVP64 that slightly break the rules
48 * [[sv/cr_int_predication]] instructions needed for effective predication
49 * [[opcode_regs_deduped]]
50 * [[sv/vector_swizzle]]
51 * [[sv/vector_ops]]
52 * [[sv/mv.swizzle]]
53 * [[sv/mv.x]]
54 * SVP64 "Modes":
55 - For condition register operations see [[sv/cr_ops]] - SVP64 Condition Register ops: Guidelines
56 on Vectorisation of any v3.0B base operations which return
57 or modify a Condition Register bit or field.
58 - For LD/ST Modes, see [[sv/ldst]].
59 - For Branch modes, see [[sv/branches]] - SVP64 Conditional Branch behaviour: All/Some Vector CRs
60 - For arithmetic and logical, see [[sv/normal]]
61 * [[sv/fcvt]] FP Conversion (due to OpenPOWER Scalar FP32)
62 * [[sv/fclass]] detect class of FP numbers
63 * [[sv/int_fp_mv]] Move and convert GPR <-> FPR, needed for !VSX
64 * [[sv/mv.vec]] move to and from vec2/3/4
65 * [[sv/sprs]] SPRs
66 * [[sv/bitmanip]]
67 * [[sv/biginteger]] Operations that help with big arithmetic
68 * [[sv/remap]] "Remapping" for Matrix Multiply and RGB "Structure Packing"
69 * [[sv/svstep]] Key stepping instruction for Vertical-First Mode
70 * [[sv/propagation]] Context propagation including svp64, swizzle and remap
71 * [[sv/vector_ops]] Vector ops needed to make a "complete" Vector ISA
72 * [[sv/av_opcodes]] scalar opcodes for Audio/Video
73 * Twin targetted instructions (two registers out, one implicit)
74 Explanation of the rules for twin register targets
75 (implicit RS, FRS) explained in SVP64 [[sv/svp64/appendix]]
76 - [[isa/svfixedarith]]
77 - [[isa/svfparith]]
78 * TODO: OpenPOWER [[openpower/transcendentals]]
79
80 Examples experiments ideas discussion:
81
82 * [[sv/masked_vector_chaining]]
83 * [[sv/discussion]]
84 * [[sv/example_dep_matrices]]
85 * [[sv/major_opcode_allocation]]
86 * [[sv/byteswap]]
87 * [[sv/16_bit_compressed]] experimental
88 * [[sv/toc_data_pointer]] experimental
89 * [[sv/predication]] discussion on predication concepts
90 * [[sv/register_type_tags]]
91
92 Additional links:
93
94 * <https://www.sigarch.org/simd-instructions-considered-harmful/>
95 * [[simple_v_extension]] old (deprecated) version
96 * [[openpower/sv/llvm]]
97 * [[openpower/sv/effect-of-more-decode-stages-on-reg-renaming]]
98
99 ===
100
101 Required Background Reading:
102 ============================
103
104 These are all, deep breath, basically... required reading, *as well as and in addition* to a full and comprehensive deep technical understanding of the Power ISA, in order to understand the depth and background on SVP64 as a 3D GPU and VPU Extension.
105
106 I am keenly aware that each of them is 300 to 1,000 pages (just like the Power ISA itself).
107
108 This is just how it is.
109
110 Given the sheer overwhelming size and scope of SVP64 we have gone to CONSIDERABLE LENGTHS to provide justification and rationalisation for adding the various sub-extensions to the Base Scalar Power ISA.
111
112 * Scalar bitmanipulation is justifiable for the exact same reasons the extensions are justifiable for other ISAs. The additional justification for their inclusion where some instructions are already (sort-of) present in VSX is that VSX is not mandatory, and the complexity of implementation of VSX is too high a price to pay at the Embedded SFFS Compliancy Level.
113
114 * Scalar FP-to-INT conversions, likewise. ARM has a javascript conversion instruction, Power ISA does not (and it costs a ridiculous 45 instructions to implement, including 6 branches!)
115
116 * Scalar Transcendentals (SIN, COS, ATAN2, LOG) are easily justifiable for High-Performance Compute workloads.
117
118 It also has to be pointed out that normally this work would be covered by multiple separate full-time Workgroups with multiple Members contributing their time and resources!
119
120 Overall the contributions that we are developing take the Power ISA out of the specialist highly-focussed market it is presently best known for, and expands it into areas with much wider general adoption and broader uses.
121
122
123 ---
124
125 OpenCL specifications are linked here, these are relevant when we get to a 3D GPU / High Performance Compute ISA WG RFC:
126 [[openpower/transcendentals]]
127
128 (Failure to add Transcendentals to a 3D GPU is directly equivalent to *willfully* designing a product that is 100% destined for commercial failure.)
129
130 I mention these because they will be encountered in every single commercial GPU ISA, but they're not part of the "Base" (core design) of a Vector Processor. Transcendentals can be added as a sub-RFC.
131
132 ---
133
134 Actual 3D GPU Architectures and ISAs:
135 -------------------------------------
136
137 * Broadcom Videocore
138 <https://github.com/hermanhermitage/videocoreiv>
139
140 * Etnaviv
141 <https://github.com/etnaviv/etna_viv/tree/master/doc>
142
143 * Nyuzi
144 <http://www.cs.binghamton.edu/~millerti/nyuziraster.pdf>
145
146 * MALI
147 <https://github.com/cwabbott0/mali-isa-docs>
148
149 * AMD
150 <https://developer.amd.com/wp-content/resources/RDNA_Shader_ISA.pdf>
151 <https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf>
152
153 * MIAOW which is *NOT* a 3D GPU, it is a processor which happens to implement a subset of the AMDGPU ISA (Southern Islands), aka a "GPGPU"
154 <https://miaowgpu.org/>
155
156
157 Actual Vector Processor Architectures and ISAs:
158 -----------------------------------------------
159
160 * NEC SX Aurora
161 <https://www.hpc.nec/documents/guide/pdfs/Aurora_ISA_guide.pdf>
162
163 * Cray ISA
164 <http://www.bitsavers.org/pdf/cray/CRAY_Y-MP/HR-04001-0C_Cray_Y-MP_Computer_Systems_Functional_Description_Jun90.pdf>
165
166 * RISC-V RVV
167 <https://github.com/riscv/riscv-v-spec>
168
169 * MRISC32 ISA Manual (under active development)
170 <https://github.com/mrisc32/mrisc32/tree/master/isa-manual>
171
172 * Mitch Alsup's MyISA 66000 Vector Processor ISA Manual is available from Mitch on direct contact with him. It is a different approach from the others, which may be termed "Cray-Style Horizontal-First" Vectorisation. 66000 is a *Vertical-First* Vector ISA.
173
174 The term Horizontal or Vertical alludes to the Matrix "Row-First" or "Column-First" technique, where:
175
176 * Horizontal-First processes all elements in a Vector before moving on to the next instruction
177 * Vertical-First processes *ONE* element per instruction, and requires loop constructs to explicitly step to the next element.
178
179 Vector-type Support by Architecture
180 [[!table data="""
181 Architecture | Horizontal | Vertical
182 MyISA 66000 | | X
183 Cray | X |
184 SX Aurora | X |
185 RVV | X |
186 SVP64 | X | X
187 """]]
188
189 ===
190
191 Obligatory Dilbert:
192
193 <img src="https://assets.amuniversal.com/7fada35026ca01393d3d005056a9545d" width="600" />
194