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 Fundamental design principles:
  10
  11 * Simplicity of introduction and implementation on the existing OpenPOWER ISA
  12 * Effectively a hardware for-loop, pausing PC, issuing multiple scalar operations
  13 * Preserving the underlying scalar execution dependencies as if the for-loop had been expanded as actual scalar instructions
  14   (termed "preserving Program Order")
  15 * Augments ("tags") existing instructions, providing Vectorisation "context" rather than adding new ones.
  16 * 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)
  17 * Designed for Supercomputing: avoids creating significant sequential
  18 dependency hazards, allowing high performance superscalar microarchitectures to be deployed.
  19
  20 Advantages of these design principles:
  21
  22 * It is therefore easy to create a first (and sometimes only) implementation as literally a for-loop in hardware, simulators, and compilers.
  23 * More complex HDL can be done by repeating existing scalar ALUs and pipelines as blocks.
  24 * 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
  25 * Completely wipes not just SIMD opcode proliferation off the
  26   map (SIMD is O(N^6) opcode proliferation)
  27   but off of Vectorisation ISAs as well.  No more separate Vector
  28   instructions.
  29
  30 Pages being developed and examples
  31
  32 * [[sv/overview]] explaining the basics.
  33 * [[sv/implementation]] implementation planning and coordination
  34 * [[sv/svp64]] contains the packet-format *only*
  35 * [[sv/setvl]] the Cray-style "Vector Length" instruction
  36 * [[sv/predication]] discussion on predication concepts
  37 * [[sv/cr_int_predication]] instructions needed for effective predication
  38 * [[sv/masked_vector_chaining]]
  39 * [[sv/discussion]]
  40 * [[sv/example_dep_matrices]]
  41 * [[sv/major_opcode_allocation]]
  42 * [[opcode_regs_deduped]]
  43 * [[sv/vector_swizzle]]
  44 * [[sv/vector_ops]]
  45 * [[sv/register_type_tags]]
  46 * [[sv/mv.swizzle]]
  47 * [[sv/mv.x]]
  48 * [[sv/branches]] - SVP64 Conditional Branch behaviour: All/Some Vector CRs
  49 * [[sv/cr_ops]] - SVP64 Condition Register ops: Guidelines
  50  on Vectorisation of any v3.0B base operations which return
  51  or modify a Condition Register bit or field.
  52 * [[sv/fcvt]] FP Conversion (due to OpenPOWER Scalar FP32)
  53 * [[sv/fclass]] detect class of FP numbers
  54 * [[sv/int_fp_mv]] Move and convert GPR <-> FPR, needed for !VSX
  55 * [[sv/mv.vec]] move to and from vec2/3/4
  56 * [[sv/16_bit_compressed]] experimental
  57 * [[sv/toc_data_pointer]] experimental
  58 * [[sv/ldst]] Load and Store
  59 * [[sv/sprs]] SPRs
  60 * [[sv/bitmanip]]
  61 * [[sv/biginteger]] Operations that help with big arithmetic
  62 * [[sv/remap]] "Remapping" for Matrix Multiply and RGB "Structure Packing"
  63 * [[sv/svstep]] Key stepping instruction for Vertical-First Mode
  64 * [[sv/propagation]] Context propagation including svp64, swizzle and remap
  65 * [[sv/vector_ops]] Vector ops needed to make a "complete" Vector ISA
  66 * [[sv/av_opcodes]] scalar opcodes for Audio/Video
  67 * [[sv/byteswap]]
  68 * Twin targetted instructions (two registers out, one implicit)
  69   Explanation of the rules for twin register targets
  70   (implicit RS, FRS) explained in SVP4 [[sv/svp64/appendix]]
  71   - [[isa/svfixedarith]]
  72   - [[isa/svfparith]]
  73 * TODO: OpenPOWER [[openpower/transcendentals]]
  74
  75 Additional links:
  76
  77 * <https://www.sigarch.org/simd-instructions-considered-harmful/>
  78 * [[simple_v_extension]] old (deprecated) version
  79 * [[openpower/sv/llvm]]
  80 * [[openpower/sv/effect-of-more-decode-stages-on-reg-renaming]]
  81
  82 ===
  83
  84 Required Background Reading:
  85 ============================
  86
  87 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.
  88
  89 I am keenly aware that each of them is 300 to 1,000 pages (just like the Power ISA itself).
  90
  91 This is just how it is.
  92
  93 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.
  94
  95 * 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.
  96
  97 * 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!)
  98
  99 * Scalar Transcendentals (SIN, COS, ATAN2, LOG) are easily justifiable for High-Performance Compute workloads.
 100
 101 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!
 102
 103 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.
 104
 105
 106 ---
 107
 108 OpenCL specifications are linked here, these are relevant when we get to a 3D GPU / High Performance Compute ISA WG RFC:
 109 [[openpower/transcendentals]]
 110
 111 (Failure to add Transcendentals to a 3D GPU is directly equivalent to *willfully* designing a product that is 100% destined for commercial failure.)
 112
 113 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.
 114
 115 ---
 116
 117 Actual 3D GPU Architectures and ISAs:
 118 -------------------------------------
 119
 120 * Broadcom Videocore
 121   <https://github.com/hermanhermitage/videocoreiv>
 122
 123 * Etnaviv
 124   <https://github.com/etnaviv/etna_viv/tree/master/doc>
 125
 126 * Nyuzi
 127   <http://www.cs.binghamton.edu/~millerti/nyuziraster.pdf>
 128
 129 * MALI
 130   <https://github.com/cwabbott0/mali-isa-docs>
 131
 132 * AMD
 133   <https://developer.amd.com/wp-content/resources/RDNA_Shader_ISA.pdf>
 134   <https://developer.amd.com/wp-content/resources/Vega_Shader_ISA_28July2017.pdf>
 135
 136 * 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"
 137   <https://miaowgpu.org/>
 138
 139
 140 Actual Vector Processor Architectures and ISAs:
 141 -----------------------------------------------
 142
 143 * NEC SX Aurora
 144   <https://www.hpc.nec/documents/guide/pdfs/Aurora_ISA_guide.pdf>
 145
 146 * Cray ISA
 147   <http://www.bitsavers.org/pdf/cray/CRAY_Y-MP/HR-04001-0C_Cray_Y-MP_Computer_Systems_Functional_Description_Jun90.pdf>
 148
 149 * RISC-V RVV
 150   <https://github.com/riscv/riscv-v-spec>
 151
 152 * MRISC32 ISA Manual (under active development)
 153   <https://github.com/mrisc32/mrisc32/tree/master/isa-manual>
 154
 155 * 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.
 156
 157 The term Horizontal or Vertical alludes to the Matrix "Row-First" or "Column-First" technique, where:
 158
 159 * Horizontal-First processes all elements in a Vector before moving on to the next instruction
 160 * Vertical-First processes *ONE* element per instruction, and requires loop constructs to explicitly step to the next element.
 161
 162 Vector-type Support by Architecture
 163 [[!table  data="""
 164 Architecture | Horizontal | Vertical
 165 MyISA 66000  |            | X
 166 Cray         | X          |
 167 SX Aurora    | X          |
 168 RVV          | X          |
 169 SVP64        | X          | X
 170 """]]
 171
 172 ===
 173
 174 Obligatory Dilbert:
 175
 176 <img src="https://assets.amuniversal.com/7fada35026ca01393d3d005056a9545d" width="600" />
 177