# Special registers

`r0l` is the hardware nesting counter.

`r1` is the hardware link register.

`r5` and `r6` are preloaded in vertex shaders to the vertex ID and instance ID.

# ABI

The following section describes the ABI used by non-monolithic programs.

## Vertex

Registers have the following layout at the beginning of the vertex shader
(written by the vertex prolog):

* `r0-r4` and `r7` undefined. This avoids preloading into the nesting counter or
  having unaligned values. The prolog is free to use these registers as
  temporaries.
* `r5-r6` retain their usual meanings, even if the vertex shader is running as a
  hardware compute shader. This allows software index fetch code to run in the
  prolog without contaminating the main shader key.
* `r8` onwards contains 128-bit uniform vectors for each attribute.
  Accommodates 30 attributes without spilling, exceeding the 16 attribute API
  minimum. For 32 attributes, we will need to use function calls or the stack.

One useful property is that the GPR usage of the combined program is equal to
the GPR usage of the main shader. The prolog cannot write higher registers than
read by the main shader.

Vertex prologs do not have any uniform registers allocated for preamble
optimization or constant promotion, as this adds complexity without any
legitimate use case.

For a vertex shader reading $n$ attributes, the following layout is used:

* The first $n$ 64-bit uniforms are the base addresses of each attribute.
* The next $n$ 32-bit uniforms are the associated clamps (sizes). Presently
  robustness is always used.
* The next 2x32-bit uniform is the base vertex and base instance. This must
  always be reserved because it is unknown at vertex shader compile-time whether
  any attribute will use instancing. Reserving also the base vertex allows us to
  push both conveniently with a single USC Uniform word.
* The next 16-bit is the draw ID.
* For a hardware compute shader, the next 48-bit is padding.
* For a hardware compute shader, the next 64-bit uniform is a pointer to the
  input assembly buffer.

In total, the first $6n + 5$ 16-bit uniform slots are reserved for a hardware
vertex shader, or $6n + 12$ for a hardware compute shader.

## Fragment

When sample shading is enabled in a non-monolithic fragment shader, the fragment
shader has the following register inputs:

* `r0l = 0`. This is the hardware nesting counter.
* `r0h` is the mask of samples currently being shaded. This usually equals to
  `1 << sample ID`, for "true" per-sample shading.

When sample shading is disabled, no register inputs are defined. The fragment
prolog (if present) may clobber whatever registers it pleases.

Registers have the following layout at the end of the fragment shader (read by
the fragment epilog):

* `r0l = 0` if sample shading is enabled. This is implicitly true.
* `r0h` preserved if sample shading is enabled.
* `r2` and `r3l` contain the emitted depth/stencil respectively, if
  depth and/or stencil are written by the fragment shader. Depth/stencil writes
  must be deferred to the epilog for correctness when the epilog can discard
  (i.e. when alpha-to-coverage is enabled).
* `r3h` contains the logically emitted sample mask, if the fragment shader uses
  forced early tests. This predicates the epilog's stores.
* The vec4 of 32-bit registers beginning at `r(4 * (i + 1))` contains the colour
  output for render target `i`. When dual source blending is enabled, there is
  only a single render target and the dual source colour is treated as the
  second render target (registers r8-r11).

Uniform registers have the following layout:

* u0_u1: 64-bit render target texture heap
* u2...u5: Blend constant
* u6_u7: Root descriptor, so we can fetch the 64-bit fragment invocation counter
  address and (OpenGL only) the 64-bit polygon stipple address