35
edits
Changes
Clarify LITP instruction
== Nomenclature ==
== Nomenclature ==
* opcode names with I appended to them are the same as their non-I version, except they use the inverted instruction format, giving 7 bits to SRC2 (and access to uniforms) and 5 bits to SRC1
* opcode names with I appended to them are the same as their non-I version, except they use the inverted instruction format, giving 7 bits to SRC2 (and access to constant registers) and 5 bits to SRC1
* opcode names with U appended to them are the same as their non-U version, except they are executed conditionally based on the value of a uniform boolean.
* opcode names with U appended to them are the same as their non-U version, except they are executed conditionally based on the value of a constant boolean register.
* opcode names with C appended to them are the same as their non-C version, except they are executed conditionally based on a logical expression specified in the instruction.
* opcode names with C appended to them are the same as their non-C version, except they are executed conditionally based on a logical expression specified in the instruction.
|}
|}
Format 3 : (used for uniform-based conditional flow control instructions)
Format 3 : (used for constant-based conditional flow control instructions)
{| class="wikitable" border="1"
{| class="wikitable" border="1"
|-
|-
| 0x16
| 0x16
| 0x4
| 0x4
| Uniform ID (BOOL/INT)
| Constant ID (BOOL/INT)
|-
|-
| 0x1A
| 0x1A
| 1
| 1
| DST
| DST
| Equivalent with Microsoft's dst instruction: DST = {1, SRC1[1]*SRC2[1], SRC1[2], SRC2[3]}
| Equivalent to Microsoft's [https://msdn.microsoft.com/en-us/library/windows/desktop/bb219790.aspx dst] instruction: DST = {1, SRC1[1]*SRC2[1], SRC1[2], SRC2[3]}
|-
|-
| 0x05
| 0x05
| 0x07
| 0x07
| 1u
| 1u
| LIT
| LITP
| Related to Microsoft's lit instruction; DST = clamp(SRC1, min={0, -127.9961, 0, 0}, max={inf, 127.9961, 0, inf})
| Partial lighting computation, may be used in conjunction with EX2, LG2, etc to compute the vertex lighting coefficients. See the [https://msdn.microsoft.com/en-us/library/windows/desktop/bb174703.aspx Microsoft] and [https://registry.khronos.org/OpenGL/extensions/ARB/ARB_vertex_program.txt ARB] docs for more information on how to implement the full lit function; DST = {max(src.x, 0), max(min(src.y, 127.9961), -127.9961), 0, max(src.w, 0)} and it sets the cmp.x and cmp.y flags based on if the respective src.x and src.w components are >= 0.
|-
|-
| 0x08
| 0x08
| 1u
| 1u
| MOVA
| MOVA
| Move to address register; Casts the float uniform given by SRC1 to an integer (truncating the fractional part) and assigns the result to (a0.x, a0.y, _, _), respecting the destination component mask.
| Move to address register; Casts the float value given by SRC1 to an integer (truncating the fractional part) and assigns the result to (a0.x, a0.y, _, _), respecting the destination component mask.
|-
|-
| 0x13
| 0x13
| 5i
| 5i
| MADI
| MADI
| Multiplies two vectors and adds a third one component by component; DST[i] = SRC3[i] + SRC2[i].SRC1[i] for all i
| Multiplies two vectors and adds a third one component by component; DST[i] = SRC3[i] + SRC2[i].SRC1[i] for all i; this is not an FMA, the intermediate result is rounded
|-
|-
| 0x38-0x3F
| 0x38-0x3F
| 5
| 5
| MAD
| MAD
| Multiplies two vectors and adds a third one component by component; DST[i] = SRC3[i] + SRC2[i].SRC1[i] for all i
| Multiplies two vectors and adds a third one component by component; DST[i] = SRC3[i] + SRC2[i].SRC1[i] for all i; this is not an FMA, the intermediate result is rounded
|}
|}
== Relative addressing ==
== Relative addressing ==
There are 3 address registers: a0.x, a0.y and aL (loop counter). For format 1 instructions, when IDX != 0, the value of the corresponding address register is added to SRC1's value. For example, if IDX = 2, a0.y = 3 and SRC1 = c8, then instead SRC1+a0.y = c11 will be used for the instruction.
{| class="wikitable" border="1"
|-
! IDX raw value
! Register name
|-
| 0x0
| None
|-
| 0x1
| a0.x
|-
| 0x2
| a0.y
|-
| 0x3
| aL
|}
There are 3 address registers: a0.x, a0.y and aL (loop counter). For format 1 instructions, when IDX != 0, the value of the corresponding address register is added to SRC1's value. For example, if IDX = 2, a0.y = 3 and SRC1 = c8, then instead SRC1+a0.y = c11 will be used for the instruction. It is only possible to use address registers on constant registers, attempting to use them on input attribute or temporary registers results in the address register being ignored (i.e. read as zero).
a0.x and a0.y are set manually through the MOVA instruction by rounding a float value to integer precision. Hence, they may take negative values.
a0.x and a0.y are set manually through the MOVA instruction by rounding a float value to integer precision. Hence, they may take negative values. The way out-of-bounds values behave when reading uniforms is as follows:
* If the offset is out of byte bounds (less than -128 or greater than 127), the offset is not applied (treated as 0).
* The offset is added to the constant register index and masked by 0x7F.
* If the resulting index is greater than 95, the result is (1, 1, 1, 1).
* Otherwise, the result is the value at the indexed constant register.
aL can only be set indirectly by the LOOP instruction. It is still accessible and valid after exiting a LOOP block, though.
aL can only be set indirectly by the LOOP instruction. It is still accessible and valid after exiting a LOOP block, though.
== Registers ==
== Registers ==
Output attribute registers (o0-o6) hold the data to be passed to the later GPU stages and are write-only. Each of the output attribute register components is assigned a semantic by setting the corresponding [[GPU_Internal_Registers]].
{| class="wikitable" border="1"
|-
! Name
! Format
! Type
! Access
! Written by
! Description
|-
| v0-v15
| vector
| float
| Read only
| Application/Vertex-stream
| Input registers.
|-
| o0-o15
| vector
| float
| Write only
| Vertex shader
| Output registers.
|-
| r0-r15
| vector
| float
| Read/Write
| Vertex shader
| Temporary registers.
|-
| c0-c95
| vector
| float
| Read only
| Application/Vertex-stream
| Floating-point Constant registers.
|-
| i0-i3
| vector
| integer
| Read only
| Application
| Integer Constant registers. (special purpose)
|-
| b0-b15
| scalar
| boolean
| Read only
| Application
| Boolean Constant registers. (special purpose)
|-
| a0.x & a0.y
| scalar
| integer
| Use/Write
| Vertex shader
| Address registers.
|-
| aL
| scalar
| integer
| Use
| Vertex shader
| Loop count register.
|}
Input attribute registers store the per-vertex data given by the CPU and hence are read-only.
Output registers hold the data to be passed to the later GPU stages and are write-only. Each of the output register is assigned a semantic by setting the corresponding [[GPU_Internal_Registers]]. Output registers o7-o15 are only available in vertex shaders.
Keep in mind that writing to the same output register/component more than once appears appears to cause problems (e.g. GPU hangs).
Temporary registers (r0-r15) can be used for intermediate calculations and can both be read and written.
Temporary registers can be used for intermediate calculations and can be both read and written.
Many shader instructions which take float arguments have only 5 bits available for the second argument. They may hence only refer to input attributes or temporary registers. In particular, it's not possible to pass two float[4] uniforms to these instructions.
Constant registers hold data uploaded by the application which remain constant throughout all processed vertices. There are 96 float[4] constant registers (c0-c95), eight boolean constant registers (b0-b7), and four int[4] constant registers (i0-i3).
Many shader instructions which take float arguments can only provide the full 7 bits for one SRC operand. All other source operands can only be used to refer to input attributes or temporary registers and cannot be passed Floating-point Constant registers.
Address registers and the Loop count register can be used to to provide relative addressing for the designated SRC operand. For more information, see the section on [[#Relative_addressing|relative addressing]].
DST mapping :
DST mapping :
! Description
! Description
|-
|-
| 0x0-0x6
| 0x0-0xF
| o0-o6
| o0-o15
| Output registers.
| Output registers.
|-
|-
{| class="wikitable" border="1"
{| class="wikitable" border="1"
|-
|-
! SRC1 raw value
! SRC raw value
! Register name
! Register name
! Description
! Description
|-
|-
| 0x0-0x7
| 0x0-0xF
| v0-v7
| v0-v15
| Input attribute registers.
| Input attribute registers.
|-
|-
| 0x20-0x7F
| 0x20-0x7F
| c0-c95
| c0-c95
| Vector uniform registers.
| Constant registers.
|}
|}
== Floating-Point Behavior ==
== Floating-Point Behavior ==
The PICA200 is not IEEE-compliant. It has positive and negative infinities and NaN, but does not seem to have negative 0. Several instructions also have behavior that differs from the IEEE functions. Here are the results from some tests done on hardware:
The PICA200 is not IEEE-compliant. It has positive and negative infinities and NaN, but does not seem to have negative 0. Input and output subnormals are flushed to +0. The internal floating point format seems to be the same as used in shader binaries: 1 sign bit, 7 exponent bits, 16 (explicit) mantissa bits. Several instructions also have behavior that differs from the IEEE functions. Here are the results from some tests done on hardware (s = largest subnormal, n = smallest positive normal):
{| class="wikitable" border="1"
{| class="wikitable" border="1"
|- style="border-top: double"
|- style="border-top: double"
| rcp(-0)
| +inf
| no -0 so differs from IEEE where rcp(-0) = -inf
|-
| rcp(0)
| rcp(0)
| +inf
| +inf
| min(-inf, +inf)
| min(-inf, +inf)
| -inf
| -inf
|
|
|- style="border-top: double"
| cmp(s, 0)
| false
| cmp does not flush input subnormals
|-
| max(s, 0)
| s
| max does not flush input or output subnormals
|-
| mul(s, 2)
| 0
| input subnormals are flushed in arithmetic instructions
|-
| mul(n, 0.5)
| 0
| output subnormals are flushed in arithmetic instructions
|}
|}
1.0 can be multiplied 63 times by 0.5 until the result compares equal zero. This is consistent with a 7-bit exponent and output subnormal flushing.
== Control Flow ==
Control flow is implemented using four independent stacks:
* 4-deep CALL stack
* 8-deep IF stack
* 4-deep LOOP stack
All stacks are initially empty. After every instruction but before JMP takes effect, the PC is incremented and a copy is sent to each stack. Each stack is checked against its copy of the PC. If an entry is popped from the stack, the copied PC is updated and used for the next check of this stack, although the IF/LOOP stacks can each only pop one entry per instruction, whereas the CALL stack is checked again until it doesn't match or the stack is empty. The updated PC copy with the highest priority wins: LOOP (highest), IF, CALL, JMP, original PC (lowest).
Special cases:
* JMP overwrites the PC *after* the stacks checks (and only if no stack was popped).
* Executing a BREAK on an empty LOOP stack hangs the GPU.
* A stack overflow discards the oldest element, so you could think of it as a queue or a ring buffer.
* If the CALL stack is popped four times in a row, the fourth update to its copy of the PC is missed (the third PC update will be propagated). Probably a hardware bug.