Xbox One GPU Overview

Introduction

Xbox One brings the enhanced capabilities of a modern Direct3D 11 GPU to the console space. The Xbox One GPU is a departure from previous console generations both in raw performance and in structure. Graphics developers targeting Xbox One will need a solid understanding of the strengths and capabilities of the underlying hardware.

The block diagram in Figure 1 lists many of the important components of the Xbox One GPU. This diagram shows only the key elements of interest to developers, and it does not accurately represent the physical size and arrangement of the components.

This white paper has been updated with finalized hardware terminology and specifications. Shader cores are now called compute units. A shader execution vector of 64 threads is now referred to as a wave. Local and global shared memory are now respectively termed local data store and global data store. Clock speed has been updated from 800 MHz to 853 MHz.

Figure 1.  Xbox One GPU block diagram.

Terms and abbreviations

The terms used in Figure 1 and elsewhere in this paper are defined in this section. Some abbreviations are standard, while others are specific to this document. More detailed descriptions of terms and abbreviations are provided in the relevant subsections of the paper.

Abbreviation Term Description
CB color block Writes and blends color.
CU compute unit Runs shader; contains four SIMDs, TCP, and LDS.
DB depth block Writes and tests depth.
ESRAM embedded static random access memory GPU on-board memory.
FLOPS floating-point operations per second  
GDS global data store Scratch memory for entire GPU.
LDS local data store Scratch memory per compute unit.
SGPR scalar general purpose register Temporary register in the compute unit.
SIMD single instruction multiple data Four instances per compute unit.
TCC texture cache per channel (L2) Shared across GPU.
TCP texture cache per pipe (L1) One instance per compute unit.
  thread A single execution instance of a shader; for example, one vertex shader or pixel shader run.
  threadgroup A collection of one or more waves that run on the same compute unit and share access to an area of the local data store.
  wave A group of 64 threads that execute in lockstep (same as a pixel/vertex vector on Xbox 360).
VGPR vector general purpose register Temporary register in the compute unit.
VSP vector scalar processor Four per SIMD, each operating on four threads per clock.

Performance

The following table describes expected performance of the Xbox One GPU. Bear in mind that the table is based only on hardware specifications, not on actual hardware running actual code. For many reasons, theoretical peak performance can be difficult or impossible to achieve with real-world processing loads.

Stat Value
Clock rate 853.33 MHz
Compute  
Compute units 12
Instruction issue rate 12 CUs * 4 SIMDs * 16 threads/clock = 768 ops/clock
FLOPs 768 ops/clock * (1 mul + 1 add) * 853.33 MHz = 1.3 TFLOPS
Interpolation ( 768 ops/clock / 2 ops ) * 853.33 MHz = 327.7 Gfloat/sec
Geometry  
Triangle rate 2 tri/clock * 853.33 MHz = 1.7 Gtri/sec
Vertex rate 2 vert/clock * 853.33 MHz = 1.7 Gvert/sec
Vertex/buffer fetch rate (4 bytes) 4 elements/clock * 12 CUs * 853.33 MHz = 41 Gelement/sec
Vertex/buffer data rate from cache 41 Gelements/sec * 4 bytes = 163.8 GB/sec
Memory  
Peak throughput from main RAM 68 GB/sec
Peak throughput from ESRAM 128 bytes/clock * 853.33 MHz = 109.2 GB/sec
ESRAM size 32 MB
GDS size 64 KB
LDS size 12 CUs * 64 KB = 768 KB
L2 cache size 4 * 128 KB = 512 KB (shared)
Texture  
Bilinear fetch rate (4 bytes) 4 fetches/clock * 12 CUs * 853.33 MHz = 41 Gtexels/sec
Bilinear data rate from cache 41 Gtexels/sec * 4 bytes = 163.8 GB/sec
TCP (L1) cache size 16 KB/CU * 12 CUs = 192 KB (nonshared)
Output  
Color/depth blocks 4
Pixel clear rate 1 8x8 tile/clock * 4 DBs * 853.33 MHz = 218.5 Gpixel/sec
Pixel hierarchical Z cull rate 1 8x8 tile/clock * 4 DBs * 853.33 MHz = 218.5 Gpixel/sec
Sample Z cull rate 16 /clock * 4 DBs * 853.33 MHz = 54.6 Gsample/sec
Pixel emit rate 4 /clock * 4 DBs * 853.33 MHz = 13.7 Gpixel/sec
Pixel resolve rate 4 /clock * 4 DBs * 853.33 MHz = 13.7 Gpixel/sec

Comparison of Xbox 360 and Xbox One GPUs

Many Xbox One developers come from an Xbox 360 background. For these developers, it will be important to break old mindsets. Following are some key differentiating features between the two GPUs. Later sections of this document will elaborate upon these differences.

Xbox 360 Xbox One
Memory  
Textures must be in off-chip (RAM) memory; render targets must be in on-chip (EDRAM) memory. On-chip (ESRAM) and off-chip (RAM) memory can be used interchangeably.
The GPU can move data into on-chip memory only by rendering, and out of on-chip memory only by resolve. The GPU contains dedicated DMA hardware for copy to and from arbitrary memory.
Compute  
Shader microcode uses a 4-wide vector instruction set along with a scalar instruction set. Shader microcode uses only a scalar instruction set.
Interpolation is performed by fixed function hardware. Interpolation is performed in the pixel shader.
Fetch  
8-bit sRGB conversion uses a piecewise linear approximation and sometimes runs at half rate. 8-bit sRGB conversion is bit accurate and runs at full rate.
Fetch via the texture unit is the same cost as raw data read. Fetch via the texture unit can cost more than raw data read.
Output  
Rendering to a 4-channel 16-bit float (half) surface runs at half rate and does not support many alpha blend modes. Rendering to a 4-channel 16-bit float (half) surface runs at full rate, and supports all alpha blend modes.
The depth test runs after the pixel shader (late z). The depth test can run before the pixel shader (early z) or after (late z).
Fill rate is usually unaffected by enabling depth test, depth write, alpha blend, or MSAA. Fill rate is often affected by enabling depth test, depth write, alpha blend, or MSAA.

Individual components and capabilities of the Xbox One GPU are described in greater detail in subsequent sections of this paper.

Command processor

Xbox One supports multiple GPU command streams interleaved in hardware. Some command streams contain rendering commands, and others are compute-only. Both types of command streams progress through the GPU at the same time, sharing compute and bandwidth resources, making it possible to decouple compute work from rendering work. In particular, compute tasks can leapfrog past pending rendering tasks, enabling low-latency handoffs between CPU and GPU.

Memory

Virtual addressing

All GPU memory accesses on Xbox One use virtual addresses, and therefore pass through a translation table before being resolved to physical addresses. This layer of indirection solves the problem of resource memory fragmentation in hardware—a single resource can now occupy several noncontiguous pages of physical memory without penalty.

Virtual addresses can target pages in main RAM or ESRAM, or can be unmapped. Shader reads and writes to unmapped pages return well-defined results, including optional error codes, rather than crashing the GPU. This facility is important for support of tiled resources, which are only partially resident in physical memory.

ESRAM

Xbox One has no video memory (VRAM) in the traditional sense, but the GPU does contain 32 MB of fast embedded SRAM (ESRAM). ESRAM on Xbox One is free from many of the restrictions that affect EDRAM on Xbox 360. Xbox One supports the following scenarios:

The difference in throughput between ESRAM and main RAM is moderate: 102.4 GB/sec versus 68 GB/sec. The advantages of ESRAM are lower latency and lack of contention from other memory clients such as the CPU, I/O, and display output. Low latency is particularly important for sustaining peak performance of the color blocks (CBs) and depth blocks (DBs).

Local data store and global data store

Each compute unit of the Xbox One GPU contains a 64-KB buffer of local data store (LDS). The LDS supplies scratch space for compute shader threadgroups. The LDS is also used implicitly for various purposes. The shader compiler can choose to allocate temporary arrays there, spill data from registers, or cache data that arrives from external memory. The LDS facilitates passing data from one pipeline stage to another (such as to interpolants, patch control points, tessellation factors, or stream out). In some cases, this usage implies that successive pipeline stages are restricted to run on the same CU.

The GPU also contains a single 64-KB buffer of global data store (GDS). The GDS contains temporary data referenced by an entire draw call. It is also used implicitly to enforce synchronization barriers, and to properly order accesses to Direct3D 11 append and consume buffers. The GDS is capable of acting as a destination for shader export, so the driver can choose to locate small render targets there for efficiency.

Caches

Xbox One has a two-stage caching system, depicted in Figure 2.

Figure 2.  Block diagram of main GPU caches; L2=TCC, L1=TCP.

Texture cache per channel (L2 cache)

The GPU contains four separate 8-way texture caches per channel (also known as L2 caches or TCCs) of 128 KB, each composed of 2048 64-byte cache lines. Each TCC owns a certain subset of address space. Texture tiling patterns are chosen to ensure all four caches are equally utilized. The TCC generally acts as a write-back cache—when the GPU modifies data in a cache line, the modifications are not written back to main memory until the cache line is evicted. The TCC mediates virtually all memory access across the entire chip, and supplies a variety of types of data, such as shader code, constants, textures, and vertices, coming either from main RAM or from ESRAM. Shader atomic operations are implemented in the TCC.

Texture cache per pipe (L1 cache)

Each compute unit has a local 64-way texture cache per pipe (also known as an L1 cache or TCP) of 16 KB, composed of 256 64-byte cache lines. The TCP generally acts as a write-through cache—when the CU modifies data in the cache, the modifications are pushed back to TCC without waiting until the cache line is evicted. The TCP is used exclusively for data that is read and written by shaders and is dedicated to coalescing memory requests over the lifetime of a single wave. Even this limited sort of caching is important because memory accesses tend to be very spatially coherent, both within one thread and across neighboring threads.

The TCP guarantees consistent ordering per thread; for example, a write followed by a read from the same address will give the updated value. However, the TCP does not ensure consistency across threads or across waves. Such requirements must be enforced explicitly—such as using barriers in the shader. Data is not shared between TCPs or between CUs except via write-back to the TCC.

Unlike some earlier GPUs (including the Xbox 360 GPU), Xbox One leaves texture and buffer data in native compressed form in the L2 and L1 caches. Compressed data implies a longer fetch pipeline—every L1 cache must now have decoder hardware in it that repeats the same calculation each time the same data is fetched. On the other hand, by keeping data compressed longer, the GPU limits cache footprint and intermediate bandwidth. Following the same principle, sRGB textures are left in gamma space in the cache, and, therefore, have the same footprint as linear textures.

To see how this policy affects cache efficiency, consider an sRGB BC1 texture—perhaps the most commonly encountered texture type in games. BC1 is a 4-bit per texel format; on Xbox One, this texture occupies 4 bits per texel in the TCP. On Xbox 360, the same texture is decompressed and gamma corrected before it reaches the cache, and therefore occupies 8 bytes per texel, or 16 times the Xbox One footprint. For this reason, the Xbox One TCP behaves like a much larger cache when compared against previous architectures.

Just as CUs can hide fetch latency by switching to other waves, L1 texture caches on Xbox One are capable of hiding L2 cache latency by continuing to process fetch instructions after a miss. In other words, when a cache miss is followed by one or more cache hits, the hits can be satisfied during the stall for the miss.

Fetch operations

Xbox One supports two types of fetch operations—fetches and buffer fetches.

Image fetches correspond to the Sample method in high-level shader language (HLSL) and require both a texture register and a sampler register. Features such as filtering, wrapping, mipmapping, gamma correction, and block compression require image fetches.

Buffer fetches correspond to the Load method in HLSL and require only a texture register, without a sampler register. Examples of buffer fetches are:

Image fetches and buffer fetches have different performance characteristics. Image fetches are generally bound by the speed of the texture pipeline and operate at a peak rate of four texels per clock. Buffer fetches are generally bound by the write bandwidth into the destination registers and operate at a peak rate of 16 GPRs per clock. In the typical case of an 8-bit four-channel texture, these two rates are identical. In other cases, such as a 32-bit one-channel texture, buffer fetch can be up to four times faster.

Many factors can reduce effective fetch rate. For example, trilinear filtering, anisotropic filtering, and fetches from volume maps all translate internally to iterations over multiple bilinear fetches. Bilinear filtering of data formats wider than 32-bits per texel also operates at a reduced rate. Floating point formats that have more than three channels operate at half rate. Use of per-pixel gradients causes fetches to operate at quarter rate.

By contrast, fetches from sRGB textures are full rate. Gamma conversion internally uses a modified 7e4 floating-point representation. This format is large enough to be bitwise exact according to the DirectX 10 spec, yet still small enough to fit through a single filtering pipe.

The Xbox One GPU supports all standard Direct3D 11 DXGI formats, as well as some custom formats.

Compute unit (CU)

Each of the 12 Xbox One CUs has its own TCP (L1) cache, LDS, and sequencer, and four SIMD units. Figure 3 shows the internal structure of one of the CUs. In the diagram, O represents a single thread of the currently executing shader.

Figure 3.  Exploded view of one compute unit.

Single instruction multiple data (SIMD)

Each of the four SIMDs in the compute unit is a wave processor in the sense of operating on waves of threads. A SIMD executes a vector instruction on 64 threads simultaneously in lockstep. Per thread, however, the SIMDs are scalar processors, in the sense of using float operands rather than float4 operands. Because the instruction set is scalar in this sense, shaders no longer waste processing power when they operate on fewer than four components at a time. Analysis of Xbox 360 shaders suggests that of the five available lanes (a float4 operation, co-issued with a float operation), only three are used on average.

The SIMD instruction set is extensive, and supports 32-bit and 64-bit integer and float data types. Operations on wider data types occupy multiple processor pipes, and therefore run at slower rates—for example, 64-bit adds are one-eighth rate, and 64-bit multiplies are 1/16-rate. Transcendental operations, such as square root, reciprocal, exponential, logarithm, sine, and cosine, are non-pipelined and run at quarter rate. These operations should be used sparingly on Xbox One because they are more expensive relative to arithmetic operations than they are on Xbox 360.

Sequencer (SQ)

The sequencer of the CU is responsible for loading shader code from memory and controlling execution of the four SIMDs. In addition to managing the SIMDs, the sequencer also executes certain types of instructions on its own. These instructions come from a separate scalar instruction set; they perform an operation per wave rather than an operation per thread. For example, a scalar instruction might be employed to add two shader constants. In microcode, scalar instructions have names beginning with s_, while vector instructions have names beginning with v_.

The sequencer tracks dependencies within a wave, keeping track of when the next instruction is safe to run. In addition, the sequencer handles dynamic branch logic and loops.

On each clock cycle, the sequencer considers one of the four SIMDs, iterating over them in a round-robin fashion. Most instructions have a four-cycle throughput, so each SIMD only needs attention once every four clocks. A SIMD can have up to 10 waves in flight at any time. The sequencer selects one or more of these 10 candidate waves to execute an instruction. The sequencer can simultaneously issue multiple instructions of different types—for example, a vector operation, a scalar operation, a global memory operation, a local memory operation, and a branch operation—but each operation must act on a different wave.

General purpose registers: VGPR and SGPR

Each SIMD contains 256 vector general purpose registers (VGPRs), and 512 scalar general purpose registers (SGPRs). Both types of GPR store 32-bit data: an SGPR contains a single 32-bit value shared across threads, while a VGPR represents an array of 32-bit values, one per thread within a wave. Each thread can only see its own entry within a VGPR.

GPRs record intermediate results between instructions of the shader. To each newly created wave, the GPU assigns a range of VGPRs and a range of SGPRs—as many as needed by the shader up to a limit of 256 VGPRs and 104 SGPRs. Some GPRs are consumed implicitly by the system—for example, to hold literal constants, index inputs, barycentric coordinates, or metadata for debugging.

The number of available GPRs can be a limiting factor in the ability of the SIMD to hide latency by switching to other waves. If all the GPRs for a SIMD are already assigned, no new wave can begin executing. And if all active waves stall, the SIMD goes idle until one of the stalls ends.

Like most modern GPUs, the Xbox One GPU uses a unified shader architecture (USA), which means that the same CUs are used interchangeably for all stages of the shader pipeline: vertex, hull, domain, geometry, pixel, and compute. On Xbox One, GPR usage is also unified; there is no longer any fixed allocation of GPRs to vertex or pixel shading as on Xbox 360.

Constants

The Xbox One GPU has no dedicated registers to hold shader constants. When a shader references a constant buffer, the compiler decides how these accesses will be implemented. The compiler can specify that constants be preloaded into GPRs. The compiler may fetch constants from memory by using scalar instructions. The compiler may cache constants in the LDS.

A shader constant may be either global (constant over the whole draw call) or indexed (immutable, but varying by thread). Indexed constants must be fetched by using vector instructions, and are correspondingly more expensive than global constants. This cost is somewhat analogous to the constant waterfalling penalty from Xbox 360, although the mechanism is different.

Branches

Branch instructions are executed by the sequencer and have the same ideal cost as computation instructions. Just as they do on CPUs, however, branches may incur pipeline stalls while awaiting the result of the instruction, which determines the branch direction. Not-taken branches introduce subsequent pipeline bubbles. Taken branches require a read from the instruction cache, which incurs an additional delay. All these potential costs are moot as long as there are enough active waves to hide the stalls.

Branching is inherently problematic on a SIMD architecture where many threads execute in lockstep, and agreement about the branch direction is not guaranteed. The HLSL compiler can implement branch logic in one of several ways:

Predication
  Both paths are executed; calculations that should not happen for a particular thread are masked out.

Predicated jump
  If all threads decide the branch in the same way, only the correct path is executed; otherwise, both paths are executed.

Skip
  Both paths are followed, but instructions that are executed by no threads are skipped over at a faster rate.

Interpolation

The Xbox One GPU has no fixed function interpolation units. Instead, a dedicated GPU component routes vertex shader output data to the LDS of whichever CU (or CUs) ends up running the pixel shader. This routing mechanism allows pixels to be shaded by a different CU than the one that shaded the associated vertices.

Before pixel shader startup, the GPU automatically populates two registers with interpolation metadata:

It is the responsibility of the shader compiler to generate microcode prologues that perform the actual interpolation calculations. The CUs have special purpose multiply-add instructions that read some of their inputs directly from the LDS. A single float interpolation across a triangle can be accomplished by using two of these instructions.

This approach to interpolation has the advantage of having no cost for unused interpolants—the instructions can be omitted or branched over. Conversely, there is no benefit from packing interpolants into float4s. Nevertheless, for short shaders, interpolation can still significantly impact overall computation load.

Output

Pixel shading output goes through the DB and CB before being written to the depth/stencil and color render targets. Logically, these buffers represent screenspace arrays, with one value per sample. Physically, implementation of these buffers is much more complex, and involves a number of optimizations in hardware.

Both depth and color are stored in compressed formats. The purpose of compression is to save bandwidth, not memory, and, in fact, compressed render targets actually require slightly more memory than their uncompressed analogues. Compressed render targets provide for certain types of fast-path rendering. A clear operation, for example, is much faster in the presence of compression, because the GPU does not need to explicitly write the clear value to every sample. Similarly, for relatively large triangles, multisample anti-aliasing (MSAA) rendering to a compressed color buffer can run at nearly the same rate as non-MSAA rendering.

For performance reasons, it is important to keep depth and color data compressed as much as possible. Some examples of operations that can destroy compression are:

Both the DB and the CB have substantial caches on die, and all depth and color operations are performed locally in the caches. Access to these caches is faster than access to ESRAM. For this reason, the peak GPU pixel rate can be larger than what raw memory throughput would indicate. The caches are not large enough, however, to fit entire render targets. Therefore, rendering that is localized to a particular area of the screen is more efficient than scattered rendering.

Fill

The GPU contains four physical instances of both the CB and the DB. Each is capable of handling one quad per clock cycle for a total throughput of 16 pixels per clock cycle, or 12.8 Gpixel/sec. The CB is optimized for 64-bit-per-pixel types, so there is no local performance advantage in using smaller color formats, although there may still be a substantial bandwidth savings.

Because alpha-blending requires both a read and a write, it potentially consumes twice the bandwidth of opaque rendering, and for some color formats, it also runs at half rate computationally. Likewise, because depth testing involves a read from the depth buffer, and depth update involves a write to the depth buffer, enabling either state can reduce overall performance.

Depth and stencil

The depth block occurs near the end of the logical rendering pipeline, after the pixel shader. However, in the GPU implementation, the DB and the CB can interact with rendering both before and after pixel shading, and the pipeline supports several types of optimized early decision pathways. Xbox One implements both hierarchical Z (Hi-Z) and early Z (and the same for stencil). Using careful driver and hardware logic, certain depth and color operations can be moved before the pixel shader, and in some cases, part or all of the cost of shading and rasterization can be avoided.

Depth and stencil are stored and handled separately by the hardware, even though syntactically they are treated as a unit. A read of depth/stencil is really two distinct operations, as is a write to depth/stencil. The driver implements the mixed format DXGI_FORMAT_D24_UNORM_S8_UINT by using two separate allocations: a 32-bit depth surface (with 8 bits of padding per sample) and an 8-bit stencil surface.

Anti-aliasing (AA)

The Xbox One GPU supports 2×, 4×, and 8× MSAA levels. It also implements a modified type of MSAA known as compressed AA. Compressed AA decouples two notions of sample:

Coverage sample
  One of several screenspace positions generated by rasterization of one pixel

Surface sample
  One of several entries representing a single pixel in a color or depth/stencil surface

Traditionally, coverage samples and surface samples match up one to one. In standard 4xMSAA, for example, a triangle may cover from zero to four samples of any given pixel, and a depth and a color are recorded for each covered sample.

Under compressed AA, there can be more coverage samples than surface samples. In other words, a triangle may still cover several screenspace locations per pixel, but the GPU does not allocate enough render target space to store a unique depth and color for each location. Hardware logic determines how to combine data from multiple coverage samples. In areas of the screen with extensive subpixel detail, this data reduction process is lossy, but the errors are generally unobjectionable. Compressed AA combines most of the quality benefits of high MSAA levels with the relaxed space requirements of lower MSAA levels.

Fixed-function components

The GPU contains four fixed-function components called DMA engines that perform various types of fast direct memory access (DMA):

DMA engine 1
  Plain copy, swizzle/unswizzle (title exclusive use)

DMA engine 2
  Plain copy, swizzle/unswizzle (title exclusive use)

DMA engine 3
  Plain copy, swizzle/unswizzle, Lempel-Ziv (LZ) lossless encode/decode (title exclusive use)

DMA engine 4
  Plain copy, swizzle/unswizzle, JPEG decode (title/system shared use)

All four DMA engines can handle arbitrary source and destination addresses in main RAM or ESRAM. Swizzle and unswizzle operations can handle all Xbox One tiling patterns.

The GPU also has a real-time hardware video encoder and decoder, both of which support the H.264 video codec. Both components are shared between the title and the system.

Display

The Xbox One GPU supports the HDMI 1.4a standard and can emit a final output signal of up to 1080p stereo 3D at 60 Hz. As on Xbox 360, the GPU uses a fixed function, high-quality scalar to resample the title’s front buffer to the consumer’s specified output resolution. The GPU accepts three independent display planes, possibly of different resolutions, and blends them into a final output by using the scalar and the source alpha channels. One display plane is controlled by the system, and two are at the disposal of the title. A common scenario will be to use these two display planes to render the game world and the UI at different resolutions.

Debugging and profiling

The Xbox One GPU contains a number of novel facilities for fine-grained debugging and performance analysis. Substantial software effort will be necessary to expose these features. Expect to hear more about this effort as the technology matures.

Summary

A processor is more than the sum of its parts. To fully understand the ramifications of the Xbox One GPU architecture will take time, experimentation, and analysis. Still, some recommendations can be made:

Above all, do not be held hostage by preconceived notions of what a GPU can do. The rules have changed, and the sky’s the limit!