Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions sycl/doc/design/spirv-extensions/targets/LICENSE
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
Copyright (c) 2025 The Khronos Group Inc.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
53 changes: 53 additions & 0 deletions sycl/doc/design/spirv-extensions/targets/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
# Targets Registry

This directory contains a registry of enumerator values for compute device targets, features and architectures to be used in Khronos extensions (such as SPV_INTEL_function_variants).

The authoritative reference file is `core.json`.
From this file the following files are generated using `generate.py`:
* `architectures.asciidoc` - to be used with the `OpSpecConditionalArchitectureINTEL` instruction
* `targets.asciidoc` - to be used with the `OpSpecConditionalTargetINTEL` instruction
* `registry.h` - contains all the values in a C header format

## Types of entries

There are two main types of entries, organized as unorded _sets_, or ordered _lists_.
In both cases, each entry has an associated integer value.

### Targets

Targets represent the device's Instruction Set Architecture (ISA), for example x86.
* The **Targets** _set_ contains the recognized targets.
* Each target has also a _set_ of **Features** which represent features/extensions of a particular target.
For example, AVX2 is an extension of the x86/x86_64 ISA and thus is available only for those targets.

_(The current lists were assembled with the help of `llc --version` and `llc --mtriple=<tgt> --mattr=help.)_

### Architectures

Architectures represent the processor's model or microarchitecture.
* Architecture **categories** define a _set_ of device types, such as CPU, GPU, or other domain-specific accelerators (eg. an AI accelerator).
* 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.).
* **Architecture** is an ordered _list_ of architectures.
Within the same category and family, it is meaningful to compare architecture to say, for example, arch. X larger than arch. Y.
Architectures with a larger enumerator value are evaluated as larger than those with smaller values.
The meaning of the ordering is defined by the vendor, but generally, newer architectures are added after older ones.

## Adding new entries & Versioning

The registry is versioned. The current version is stored in `core.json` and from there propagated to the generated files.

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.
Adding entries this way is backwards-compatible and does not require incrementing the version number.
Likewise, adding a new alias to an existing enumerator value is backwards-compatible.

Any changes to the meaning of existing enumerator values are backwards-incompatible and should be as rare as possible.
This includes, for example, removing an entry, adding an architecture somewhere else than at the end of the ordered list, or reordering the architectures.
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.

Version 0 is used for the initial draft until the SPV_INTEL_function_variants extension is ratified as EXT or KHR.
Until then, contents of the registry is subject to change and breaking changes can occur.

## TODO

* Use templating engine like [Mako](https://www.makotemplates.org) to handle the file generation.
* Improve the generated header to include also C++ header using C++ features.
Loading