3 # Letter regarding ISAMUX / NS
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:
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
15 All of these are set by one instruction, that, once set, radically
16 changes the entire behaviour and characteristics of subsequent instructions.
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.
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
31 Instructions that we need to add, which are a normal part of GPUs,
32 include ATAN2, LOG, NORMALISE, YUV2RGB, Khronos Compliance FP mode
33 (different from both IEEE754 and "NI" mode), and many more. Many of
34 these may turn out to be useful in a wider context: they however need
35 to be fully isolated behind "mode-setting".
37 # Summary of Libre-SOC Commercial Project
39 The Libre-SOC Commercial Product is a hybrid GPU-GPU-VPU intended for
40 mass-volume production. There is no separate GPU, because the CPU
41 *is* the GPU. There is no separate VPU, because the CPU *is* the GPU.
42 There is not even a separate pipeline: the CPU pipelines *are* the
43 GPU and VPU pipelines.
45 Closest equivalents include the ARC core (which has VPU extensions and
46 3D extensions in the form of Broadcom's VideoCore IV) and the ICubeCorp
47 IC3128. Both are considered "hybrid" CPU-GPU-VPU processors.
49 "Normal" Commercial GPUs are entirely separate processors. The development
50 cost and complexity purely in terms of Software Drivers alone is immense.
51 We reject that approach (and as a small team we do not have the resources
54 With the project being Libre - not proprietary and secretive and never
55 to be published, ever - it is no good having the extensions as "custom"
56 because "custom" is specifically for the cases where the augmented
57 toolchain is never, under any circumstances, published and made public by
58 the proprietary company (and would never be accepted upstream anyway).
59 For business commercial reasons, Libre-SOC is the total opposite of this
60 proprietary, secretive approach.
62 Therefore, to meet our business objectives:
64 * As shown from Nyuzi and Larrabee, although ideally suited to high
65 performance compute tasks, a "traditional" general-purpose full
66 IEEE754-compliant Vector ISA (such as that in POWER9) is not an adequate
67 basis for a commercially competitive GPU. Nyuzi's conclusion is that
68 using such general-purpose Vector ISAs results in reaching only 25%
69 performance (or requiring 4-fold increase in power consumption) to
70 achieve par with current commercial-grade GPUs.
71 * We are not going the "traditional" (separate custom GPU) route because
72 it is not practical for a new team to design hardware and spend 8+
73 man-years on massively complex inter-processor driver development as well
74 * We cannot meet our objectives with a "custom extension" because the
75 financial burden on our team to maintain a total hard fork of not just
76 toolchains, but also entire GNU/Linux Distros, is highly undesirable,
77 and completely impractical (and Redhat would strongly object anyway)
78 * We cannot "go ahead anyway" because to do so would be highly irresponsible
79 and cause massive disruption to the POWER community.
81 With all impractical options eliminated the only remaining responsible
82 option is to extend the POWER ISA in an atomically-managed (IANA-style)
83 formal fashion, whilst (critically and absolutely essentially) always
84 providing a PCR compatibility mode that is fully POWER compliant.