View source for Geometry Transformation Engine (GTE)

This is an old revision of this page, as edited by RemmyLee at 02:46, 23 October 2026. Publishing it replaces the current version.
← Geometry Transformation Engine (GTE)
You do not have permission to edit this page. Log in to edit.
---
title: Geometry Transformation Engine (GTE)
type: component
summary: Fixed-point vector and matrix coprocessor of the PlayStation CPU.
category: Hardware
---

## Overview

The GTE is a vector and matrix processor implemented as coprocessor 2 of the [CPU](/hardware/cpu/) under the MIPS architecture specification. It handles fixed-point real numbers and executes coordinate transformation and light source calculation for the CPU at high speed.[^hw14] [^ipr43] The [GPU](/hardware/gpu/) then draws polygons from the coordinates and color information that the GTE produces.[^hw14]

A single GTE command performs a whole series of calculations needed for graphics: coordinate transformation, perspective transformation and light source calculation. General matrix and vector calculations such as matrix multiplication, outer product and interpolation are also available as commands. In each case the calculation is several times faster than the same calculation performed by the CPU.[^ipr45]

The GTE has no memory and no I/O port on the CPU bus. The CPU therefore reaches it only through coprocessor instructions: register moves, register loads and stores, and the cop2 instruction that issues a command.[^spxop] The [register reference](/hardware/gte/registers/) and the [command reference](/hardware/gte/commands/) describe each register and each command.

## Registers

The GTE has 32 data registers and 32 control registers of 32 bits each. The CPU accesses them in register units. However, some registers are divided into several 8-bit or 16-bit fields. A matrix control register, for example, holds two 16-bit elements.[^ipr43] [^ipr55] While the GTE performs a calculation, only GTE registers are referenced or changed.[^ipr43]

The following CPU instructions move data between GTE registers and CPU registers or between GTE registers and main memory (including the scratchpad):

Table: GTE register access instructions

| CPU Instruction | Source | Destination |
| --- | --- | --- |
| lwc2 | Memory or scratchpad | GTE data register |
| swc2 | GTE data register | Memory or scratchpad |
| mtc2 | CPU general-purpose register | GTE data register |
| mfc2 | GTE data register | CPU general-purpose register |
| ctc2 | CPU general-purpose register | GTE control register |
| cfc2 | GTE control register | CPU general-purpose register |

The register move instructions mtc2, mfc2, ctc2 and cfc2 are delayed loads, as are memory accesses on the cache. A program must therefore place a nop in the delay slot before it uses the loaded value:[^ipr43]

```
cfc2    v0,C2_FLAG
nop                     # delay slot
and     v0,v0,v1
```

The header file gtereg.h defines the register names as macros. Each macro is the register name from the GTE Register Specification with the prefix C2_. VXY0 therefore becomes C2_VXY0.[^ipr44] psx-spx reports that CFC2 and MFC2 load the CPU register one instruction late, and names Tekken 2 as a game whose geometry breaks when this delay is not reproduced.[^spxdelay]

## Delay Slots and Execution Cycles

An instruction that executes a GTE command (cop2) requires two delay slots after the preceding GTE instruction. A register load directly before a command is therefore followed by two nops:[^ipr45]

```
mtc2    v0,C2_VXY0
nop                     # delay slot
nop                     # delay slot
RTPS
```

The [command reference](/hardware/gte/commands/) lists the fixed number of cycles that each command takes. The CPU keeps executing while the command runs. However, the CPU stalls until the first command completes if a GTE register read (swc2, mfc2, cfc2) or another cop2 command is issued before the prescribed number of cycles has passed. CPU instructions placed between the command and the read therefore use the wait instead of losing it.[^ipr45]

## Coding Limitations

Sony gives the following rules for code that uses the GTE:[^ipr45]

Table: GTE coding limitations

| No. | Rule |
| --- | --- |
| 1 | A GTE instruction (cop2) must not be executed in an event handler or callback function. |
| 2 | A GTE instruction (cop2) must not be inserted into the delay slot following a jump or branch instruction. |
| 3 | A GTE register access instruction (lwc2, swc2, mtc2, mfc2, ctc2, cfc2) must not be inserted into the delay slot following a jump or branch. |
| 4 | A GTE register load instruction (lwc2, mtc2, ctc2) must not be used between a GTE instruction and a GTE register save instruction (swc2, mfc2, cfc2), or between two GTE instructions. |

Rule 4 has an exception. A load to a register that the running command neither references nor overwrites may be executed without regard to the command, so mtc2 to VXY1 during RTPS and mtc2 to RGB during RTPT are both allowed.[^ipr46]

Assembler code that breaks these rules may appear to run correctly at first. The faults appear later as bugs that are hard to trace. Wrong operation during an interrupt is one example. For this reason Sony advises against coding the GTE directly in assembler. Sony recommends developing in C with libgte first. The program then moves to C with DMPSX and to assembler with DMPSX last.[^ipr46]

## Number Format

Sony writes a GTE fixed-point format as (a.b.c), where the sign portion is a bits, the integer portion b bits and the fractional portion c bits. The format (-.b.-) is b bits of plain binary data.[^ipr64] The matrix elements are (1.3.12), the translation vector is (1.31.0) and the screen offset is (1.15.16), so each register carries its own scale.[^ipr55]

## Limiters

During some calculations a result is clipped when it passes a lower or upper limit: a value below the lower limit becomes the lower limit and a value above the upper limit becomes the upper limit. Sony calls these functions limiters. Each clip also sets an out-of-bounds bit in the FLAG register, so a program can detect it after the command.[^ipr63] The [register reference](/hardware/gte/registers/) lists the limiters and the FLAG bits.

## DMPSX

DMPSX is a post-processor tool that lets a program control the GTE through inline macros instead of libgte function calls. Because the calls are removed, instruction cache misses are reduced and the program runs faster. A program that uses DMPSX is compiled to an object file, the object file is passed through dmpsx.exe, and the output is then linked with the other objects.[^ipr13]

## References

[^hw14]: Sony Computer Entertainment Inc. PlayStation Hardware. August 1998. Page 1-4.
[^ipr13]: Sony Computer Entertainment Inc. Inline Programming Reference. November 1998. Page 1-3.
[^ipr43]: Sony Computer Entertainment Inc. Inline Programming Reference. November 1998. Page 4-3.
[^ipr44]: Sony Computer Entertainment Inc. Inline Programming Reference. November 1998. Page 4-4.
[^ipr45]: Sony Computer Entertainment Inc. Inline Programming Reference. November 1998. Page 4-5.
[^ipr46]: Sony Computer Entertainment Inc. Inline Programming Reference. November 1998. Page 4-6.
[^ipr55]: Sony Computer Entertainment Inc. Inline Programming Reference. November 1998. Pages 5-5 to 5-27, control registers.
[^ipr63]: Sony Computer Entertainment Inc. Inline Programming Reference. November 1998. Page 6-3.
[^ipr64]: Sony Computer Entertainment Inc. Inline Programming Reference. November 1998. Page 6-4.
[^spxop]: psx-spx. Geometry Transformation Engine (GTE), GTE Operation. https://psx-spx.consoledev.net/geometrytransformationenginegte/
[^spxdelay]: psx-spx. Geometry Transformation Engine (GTE), GTE Load Delay Slots. https://psx-spx.consoledev.net/geometrytransformationenginegte/