|
| 1 | +# Targets Registry |
| 2 | + |
| 3 | +**Version: 0** |
| 4 | + |
| 5 | +This directory contains a registry of enumerator values for compute device targets, features and architectures used in the SPV_INTEL_function_variants extension. |
| 6 | +Other extensions can also adapt this registry |
| 7 | + |
| 8 | +The authoritative reference file is `core.json`. |
| 9 | +From this file the following files are generated using `generate.py`: |
| 10 | +* `architectures.asciidoc` - to be used with the `OpSpecConditionalArchitectureINTEL` instruction |
| 11 | +* `targets.asciidoc` - to be used with the `OpSpecConditionalTargetINTEL` instruction |
| 12 | +* `registry.h` - contains all the values in a C header format |
| 13 | + |
| 14 | +## Types of entries |
| 15 | + |
| 16 | +There are two main types of entries, organized as unorded _sets_, or ordered _lists_. |
| 17 | +In both cases, each entry has an associated integer value. |
| 18 | + |
| 19 | +### Targets |
| 20 | + |
| 21 | +Targets represent the device's Instruction Set Architecture (ISA), for example x86. |
| 22 | +* The **Targets** _set_ contains the recognized targets. |
| 23 | +* Each target has also a _set_ of **Features** which represent features/extensions of a particular target. |
| 24 | +For example, AVX2 is an extension of the x86/x86_64 ISA and thus is available only for those targets. |
| 25 | + |
| 26 | +### Architectures |
| 27 | + |
| 28 | +Architectures represent the processor's model or microarchitecture. |
| 29 | +* Architecture **categories** define a _set_ of device types, such as CPU, GPU, or other domain-specific accelerators (eg. an AI accelerator). |
| 30 | +* Architecture **families** define a _set_ of distinct lines of products within each category. This generally means a vendor, but can also represent two types of devices of the same category within one vendor that are not directly comparable (eg. Vendor X has two lines of CPUs: high-performance CPUs for servers and low-power CPUs for embedded.). |
| 31 | +* **Architecture** is an ordered _list_ of architectures. |
| 32 | +Within the same category and family, it is meaningful to compare architecture to say, for example, arch. X larger than arch. Y. |
| 33 | +Architectures with a larger enumerator value are evaluated as larger than those with smaller values. |
| 34 | +The meaning of the ordering is defined by the vendor, but generally, newer architectures are added after older ones. |
| 35 | + |
| 36 | +## Adding new entries & Versioning |
| 37 | + |
| 38 | +Adding a new entry to one of the sets or lists is done by incrementing the enumerator and adding the entry at the end of the set / list. |
| 39 | +Adding entries this way is backwards-compatible and does not require incrementing the version number. |
| 40 | +Likewise, adding a new alias to an existing enumerator value is backwards-compatible. |
| 41 | + |
| 42 | +Any changes to the meaning of existing enumerator values are backwards-incompatible and should be as rare as possible. |
| 43 | +This includes, for example, removing an entry, adding an architecture somewhere else than at the end of the ordered list, or reordering the architectures. |
| 44 | +In such cases, the version should be incremented, specifications using this repository will need to update the version, and finally the implementations of the specifications need to adapt to the changed version. |
| 45 | + |
| 46 | +Version 0 is used for the initial draft until the SPV_INTEL_function_variants extension is ratified as EXT or KHR. |
| 47 | +Until then, contents of the registry is subject to change and breaking changes can occur. |
0 commit comments