openpower/isans_letter.mdwn

   1 (Draft Status)
   2
   3 # Letter regarding ISAMUX / NS
   4
   5 This is a quick overview of the way that we would like to add changes
   6 that we are proposing to the PowerPC instruction set.  It is based on
   7 a Open Standardisation of the way that existing "mode switches",
   8 already found in the POWER instruction set, are added:
   9
  10 * FPSCR's "NI" bit, setting non-IEEE754 FP mode
  11 * MSR's "LE" bit (and associated HILE bit), setting little-endian mode
  12 * MSR's "SF" bit, setting either 32-bit or 64-bit mode
  13 * PCR's "compatibility" bits 60-62, V2.05 V2.06 V2.07 mode
  14
  15 All of these are set by one instruction, that, once set, radically
  16 changes the entire behaviour and characteristics of subsequent instructions.
  17
  18 With these (and other) long-established precedents already in POWER,
  19 there is therefore essentially conceptually nothing new about what we
  20 propose: we simply seek that the process by which such "switching" is
  21 added is formalised and standardised, such that we (and others) have
  22 a clear, standards-non-disruptive, atomic and non-intrusive path to
  23 extend the POWER ISA for use in markets that it presently cannot enter.
  24
  25 We advocate that some of "mode-setting" (escape-sequencing) bits be binary
  26 encoded, some unary encoded, some "offical", some "experimental" and some
  27 "reserved".  The available space in a suitably-chosen SPR to be formalised,
  28 and the OpenPOWER Foundation to be given an IANA-like role in atomically
  29 allocating mode bits.
  30
  31 # Summary of Libre-SOC Commercial Project
  32
  33 The Libre-SOC Commercial Product is a hybrid GPU-GPU-VPU intended for
  34 mass-volume production.  There is no separate GPU, because the CPU
  35 *is* the GPU.  There is no separate VPU, because the CPU *is* the GPU.
  36 There is not even a separate pipeline: the CPU pipelines *are* the
  37 GPU and VPU pipelines.
  38
  39 Closest equivalents include the ARC core (which has VPU extensions and
  40 3D extensions in the form of Broadcom's VideoCore IV) and the ICubeCorp
  41 IC3128.  Both are considered "hybrid" CPU-GPU-VPU processors.
  42
  43 "Normal" Commercial GPUs are entirely separate processors.  The development
  44 cost and complexity purely in terms of Software Drivers alone is immense.
  45 We reject that approach (and as a small team we do not have the resources
  46 anyway).
  47
  48 With the project being Libre - not proprietary and secretive and never
  49 to be published, ever - it is no good having the extensions as "custom"
  50 because "custom" is specifically for the cases where the augmented
  51 toolchain is never, under any circumstances, published and made public by
  52 the proprietary company (and would never be accepted upstream anyway).
  53 For business commercial reasons, Libre-SOC is the total opposite of this
  54 proprietary, secretive approach.
  55
  56 Therefore, to meet our business objectives:
  57
  58 * A "traditional" general-purpose Vector System (such as that in POWER9)
  59   is *NOT* an adequate basis for a GPU.  Nyuzi's conclusion is that using
  60   such general-purpose Vector ISAs results in reaching only 25% performance
  61    (or requiring 4-fold increase in power consumption) to achieve par with
  62    current commercial-grade GPUs.
  63 * We are not going the "traditional" (separate custom GPU) route because
  64   it is not practical for a new team to design hardware and spend 8+
  65   man-years on massively complex inter-processor driver development as well
  66 * We cannot meet our objectives with a "custom extension" because the
  67   financial burden on our team to maintain a total hard fork of not just
  68   toolchains, but also entire GNU/Linux Distros, is highly undesirable,
  69   and completely impractical (and Redhat would strongly object anyway)
  70 * We cannot "go ahead anyway" because to do so would be highly irresponsible
  71   and cause massive disruption to the POWER community.
  72
  73 With all impractical options eliminated the only remaining responsible
  74 option is to extend the POWER ISA in an atomically-managed (IANA-style)
  75 formal fashion, whilst (critically and absolutely essentially) always
  76 providing a PCR compatibility mode that is fully POWER compliant.
  77